From mkosek at redhat.com Fri Nov 1 19:16:19 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 01 Nov 2013 20:16:19 +0100 Subject: [Freeipa-users] Announcing FreeIPA 3.3.3 Message-ID: <5273FE03.30007@redhat.com> The FreeIPA team is proud to announce FreeIPA v3.3.3! It can be downloaded from http://www.freeipa.org/page/Downloads. Fedora 19 and Fedora 20 builds are already on their way to updates-testing repo. == Highlights in 3.3.3 == === Enhancements === * New ipa-advise plugins for configuring legacy clients via nss-pam-ldapd * New ipa-advise plugins for configuring legacy clients via nss_ldap * FreeIPA server can now co-exist with mod_ssl serving other non-443 ports === Bug fixes === * ipa-replica-install no longer crashes when being installed with a CA support * winsync reinitialization no longer prints error * Samba configuration added by ipa-adtrust-install is now properly removed * Administrative password changes (e.g. by Directory Manager) now respect maximum password life as defined in password policy * nsds5ReplicaStripAttrs is now properly set on replication agreements, avoiding potential replication issues * ... and numerous other small fixes === Test improvements === * New integration test for external CA installation * New integration tests for AD Trust legacy clients feature * Numerous small fixes in test framework and beaker integration === Deprecated functionality === * DNS can no longer be configured with --no-serial-autoincrement option. Serial autoincrement is a requirement for several DNS main features, including zone transfers and future DNSSEC support * LanMan hash is no longer supported or generated. LanMan hash has several security weaknesses allowing attacker to crack it in a reasonable time. As such, the LanMan hash was already not allowed in a default configuration and had to be explicitly enabled. == Upgrading == An IPA server can be upgraded simply by installing updated rpms. The server does not need to be shut down in advance. === Upgrading old FreeIPA servers with CA === Upgrades of FreeIPA servers with CA installed prior to 3.1 requires manual migration procedure. Please note that if you are doing the upgrade in special environment (e.g. FedUp) which does not allow running the LDAP server during upgrade process, upgrade scripts need to be run manually after the first boot: # ipa-upgradeconfig # ipa-ldap-updater --upgrade Also note that the performance improvements require an extended set of indexes to be configured. RPM update for an IPA server with a excessive number of users 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 and later versions is supported. Upgrading from previous versions is not supported and has not been tested. An enrolled client does not need the new packages installed unless you want to re-enroll it. SSH keys for already installed clients are not uploaded, you will have to re-enroll the client or manually upload the keys. == Feedback == Please provide comments, bugs and other feedback via the freeipa-users mailing list (http://www.redhat.com/mailman/listinfo/freeipa-users) or #freeipa channel on Freenode. == Detailed Changelog since 3.3.2 == === Ana Krivokapic (4): === * Add ipa-advise plugins for nss-pam-ldapd legacy clients * Do not roll back failed client installation on server * Make sure nsds5ReplicaStripAttrs is set on agreements * Add test for external CA installation === Jakub Hrozek (1): === * trusts: combine filters with AND to make sure only the intended domain matches === Jan Cholasta (1): === * Track DS certificate with certmonger on replicas. === Martin Kosek (14): === * Do not allow '%' in DM password * Remove --no-serial-autoincrement * PKI installation on replica failing due to missing proxy conf * Use consistent realm name in cainstance and dsinstance * Winsync re-initialize should not run memberOf fixup task * Installer should always wait until CA starts up * Administrative password change does not respect password policy * Do not add kadmin/changepw ACIs on new installs * Make set_directive and get_directive more strict * Remove mod_ssl conflict * Add nsswitch.conf to FILES section of ipa-client-install man page * Remove ipa-pwd-extop and ipa-enrollment duplicate error strings * Remove deprecated AllowLMhash config * Become IPA 3.3.3 === Petr Viktorin (6): === * test_caless.TestCertInstall: Fix 'test_no_ds_password' test case * Use new CLI options in certinstall tests * test_simple_replication: Fix waiting for replication * freeipa.spec: Fix changelog dates * Tests: mkdir_recursive: Don't fail when top-level directory doesn't exist * beakerlib plugin: Don't try to submit logs if they are missing === Petr Vobornik (1): === * Fix password expiration notification === Sumit Bose (3): === * Use the right attribute with ipapwd_entry_checks for MagicRegen * Remove AllowLMhash from the allowed IPA config strings * Remove generation and handling of LM hashes === Tomas Babej (23): === * trusts: Do not create ranges for subdomains in case of POSIX trust * ipa-upgradeconfig: Remove backed up smb.conf * ipa-adtrust-install: Add warning that we will break existing samba configuration * adtrustinstance: Properly handle uninstall of AD trust instance * adtrustinstance: Move attribute definitions from setup to init method * ipatests: Extend the order plugin to properly handle inheritance * Get the created range type in case of re-establishing trust * ipatests: Add Active Directory support to configuration * ipatests: Extend domain object with 'ad' role support and WinHosts * ipatests: Extend IntegrationTest with multiple AD domain support * ipatests: Create util module for ipatests * ipatests: Add WinHost class * ipatests: Add AD-integration related tasks * ipatests: Add AD integration test case * trusts: Fix typo in error message for realm-domain mismatch * advice: Add legacy client configuration script using nss-ldap * ipatests: Extend clear_sssd_cache to support non-systemd platforms * ipatests: Restore SELinux context after restoring files from backup * ipatests: Do not use /usr/bin hardcoded paths * ipatests: Add support for extra roles referenced by a keyword * ipatests: Use command -v instead of which in legacy client advice * ipatests: Add integration tests for legacy clients * ipatests: test_trust: use domain name instead of realm for user lookups From fvzwieten at vxcompany.com Sun Nov 3 07:12:57 2013 From: fvzwieten at vxcompany.com (Fred van Zwieten) Date: Sun, 3 Nov 2013 08:12:57 +0100 Subject: [Freeipa-users] vsftpd and IPA and openldap Message-ID: Hi there, I have a question. We have a vsftpd service running which authenticates it's virtual users against an application level openldap database. No IPA involved here. It works using pam_ldap. The virtual users are mapped to a local user thru the "guest_user=" directive in vsftpd.conf. As the vsftpd service is running on a IPA client (RHEL6), I was kind of hoping this "local user" would in fact be a IPA user. Nope. He must currently live in /etc/passwd. This is, I suspect, because we have a different pam file for vsftpd to be able to communicate with the application openldap, making it impossible to also use IPA. I there a way to have the vsftpd check (and use) with IPA for it's local users and the application level openldap service for it's virtual users? This is the pam file vsftpd came with originally: #%PAM-1.0 session optional pam_keyinit.so force revoke auth required pam_listfile.so item=user sense=deny file=/etc/vsftpd/ftpusers onerr=succeed auth required pam_shells.so auth include password-auth account include password-auth session required pam_loginuid.so session include password-auth And this is the pam file we now use: #%PAM-1.0 auth required /lib64/security/pam_ldap.so account required /lib64/security/pam_ldap.so session required /lib64/security/pam_ldap.so password required /lib64/security/pam_ldap.so Thanks for any answer. Cheers, Fred -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Mon Nov 4 20:09:31 2013 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 04 Nov 2013 15:09:31 -0500 Subject: [Freeipa-users] vsftpd and IPA and openldap In-Reply-To: References: Message-ID: <5277FEFB.3030802@redhat.com> On 11/03/2013 02:12 AM, Fred van Zwieten wrote: > Hi there, > > I have a question. We have a vsftpd service running which > authenticates it's virtual users against an application level openldap > database. No IPA involved here. It works using pam_ldap. The virtual > users are mapped to a local user thru the "guest_user=" > directive in vsftpd.conf. As the vsftpd service is running on a IPA > client (RHEL6), I was kind of hoping this "local user" would in fact > be a IPA user. Nope. He must currently live in /etc/passwd. This is, I > suspect, because we have a different pam file for vsftpd to be able to > communicate with the application openldap, making it impossible to > also use IPA. > > I there a way to have the vsftpd check (and use) with IPA for it's > local users and the application level openldap service for it's > virtual users? > > This is the pam file vsftpd came with originally: > > #%PAM-1.0 > session optional pam_keyinit.so force revoke > auth requiredpam_listfile.so item=user sense=deny > file=/etc/vsftpd/ftpusers onerr=succeed > auth requiredpam_shells.so > auth includepassword-auth > account includepassword-auth > session required pam_loginuid.so > session includepassword-auth > > > And this is the pam file we now use: > > #%PAM-1.0 > authrequired/lib64/security/pam_ldap.so > accountrequired/lib64/security/pam_ldap.so > session required /lib64/security/pam_ldap.so > password required /lib64/security/pam_ldap.so > > Thanks for any answer. > > Cheers, > > Fred > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users If you configure SSSD with 2 domains one IPA another LDAP and then tell vsftpd to use pam_sss in pam stack instead of the pam_ldap you will be able to authenticate users coming from both sources. Effectively you need to take your pam_ldap configuration translate it into sssd.conf settings for the second domain (do not touch the one that you already have, just add another one) and then switch the pam config for vsftpd. This should result in what you are looking for. -- 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 tompos at martos.bme.hu Tue Nov 5 12:32:36 2013 From: tompos at martos.bme.hu (Tamas Papp) Date: Tue, 05 Nov 2013 13:32:36 +0100 Subject: [Freeipa-users] ui login error and questions about replication Message-ID: <5278E564.6030403@martos.bme.hu> hi, The systems are uptodate F19 KVM guests. I'm trying to login the web ui with no success: "Your session has expired. Please re-login. To login with Kerberos, please make sure you have valid tickets (obtainable via kinit) and configured the browser correctly, then click Login. To login with username and password, enter them in the fields below then click Login." Then after a while something happens and it starts working. In logs: On the "primary" node: [05/Nov/2013:12:19:06 +0100] NSMMReplicationPlugin - agmt="cn=meToipa12.bpo.cxn" (ipa12:389): Replication bind with GSSAPI auth resumed On the "secondary" node: [05/Nov/2013:12:31:25 +0100] csngen_new_csn - Warning: too much time skew (-1658 secs). Current seqnum=3 [05/Nov/2013:12:45:33 +0100] csngen_new_csn - Warning: too much time skew (-811 secs). Current seqnum=a [05/Nov/2013:12:45:33 +0100] csngen_new_csn - Warning: too much time skew (-812 secs). Current seqnum=1 [05/Nov/2013:12:45:35 +0100] csngen_new_csn - Warning: too much time skew (-811 secs). Current seqnum=1 [05/Nov/2013:12:45:47 +0100] csngen_new_csn - Warning: too much time skew (-800 secs). Current seqnum=4 [05/Nov/2013:12:45:47 +0100] csngen_new_csn - Warning: too much time skew (-801 secs). Current seqnum=1 [05/Nov/2013:12:45:49 +0100] csngen_new_csn - Warning: too much time skew (-800 secs). Current seqnum=1 Date shows up the same system time on both machines: Tue Nov 5 12:59:29 CET 2013 I called as primary the machine that was installed initially and secondary is the one that was deployed by replication. Finally, I have some questions:) 1. How can this happen, what's the problem? Is it something about the design, I screwed up something, or maybe the virtualization layer..? How can I avoid it and if it happens, how can I fix it immediately? 2. What is the difference between 'primary' and 'secondary'. What does happen, if the primary machine gets destroyed? 4. How many "master" can I use? 5. If I have a network like this: A1______B1 A2 B2 A2 and B1,2 are replicated from A1 If the connection gets lost between A and B site, are B1 and 2 (and A1,2) replicated fine? 6. If a client is installed with ipa-client-install using A1 and A1 gets lost, does the client know, where it needs to connect (failover..)? 7. Can I install slave (read-only) replicas so clients access them only for queries and for changes (like pw change) they access master servers? Thanks, tamas -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Tue Nov 5 13:04:25 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 5 Nov 2013 15:04:25 +0200 Subject: [Freeipa-users] ui login error and questions about replication In-Reply-To: <5278E564.6030403@martos.bme.hu> References: <5278E564.6030403@martos.bme.hu> Message-ID: <20131105130425.GE25335@redhat.com> On Tue, 05 Nov 2013, Tamas Papp wrote: >hi, > >The systems are uptodate F19 KVM guests. > > >I'm trying to login the web ui with no success: > >"Your session has expired. Please re-login. > >To login with Kerberos, please make sure you have valid tickets >(obtainable via kinit) and configured > the browser >correctly, then click Login. > >To login with username and password, enter them in the fields below then >click Login." > > >Then after a while something happens and it starts working. > >In logs: > >On the "primary" node: > >[05/Nov/2013:12:19:06 +0100] NSMMReplicationPlugin - >agmt="cn=meToipa12.bpo.cxn" (ipa12:389): Replication bind with GSSAPI >auth resumed > > >On the "secondary" node: > >[05/Nov/2013:12:31:25 +0100] csngen_new_csn - Warning: too much time >skew (-1658 secs). Current seqnum=3 >[05/Nov/2013:12:45:33 +0100] csngen_new_csn - Warning: too much time >skew (-811 secs). Current seqnum=a >[05/Nov/2013:12:45:33 +0100] csngen_new_csn - Warning: too much time >skew (-812 secs). Current seqnum=1 >[05/Nov/2013:12:45:35 +0100] csngen_new_csn - Warning: too much time >skew (-811 secs). Current seqnum=1 >[05/Nov/2013:12:45:47 +0100] csngen_new_csn - Warning: too much time >skew (-800 secs). Current seqnum=4 >[05/Nov/2013:12:45:47 +0100] csngen_new_csn - Warning: too much time >skew (-801 secs). Current seqnum=1 >[05/Nov/2013:12:45:49 +0100] csngen_new_csn - Warning: too much time >skew (-800 secs). Current seqnum=1 > > >Date shows up the same system time on both machines: > >Tue Nov 5 12:59:29 CET 2013 > >I called as primary the machine that was installed initially and >secondary is the one that was deployed by replication. Virtual Machines are known to have issues with keeping time in sync. >Finally, I have some questions:) > >1. How can this happen, what's the problem? Is it something about the >design, I screwed up something, or maybe the virtualization layer..? >How can I avoid it and if it happens, how can I fix it immediately? It is virtualization/time issue. https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Virtualization_for_Desktops/2.2/html/Administration_Guide/chap-Virtualization-KVM_guest_timing_management.html >2. What is the difference between 'primary' and 'secondary'. What does >happen, if the primary machine gets destroyed? In IPA all replicas are the same, they only would differ by the paths they sync with each other and by presence of integrated CA (if any). If you have deployed original IPA server with integrated CA, then your other replicas better to have at least one with CA configured to allow proper recovery in case primary one is destroyed. >4. How many "master" can I use? Technically there could be 65536 different masters in 389-ds replication topology. >5. If I have a network like this: > >A1______B1 >A2 B2 > >A2 and B1,2 are replicated from A1 > >If the connection gets lost between A and B site, are B1 and 2 (and >A1,2) replicated fine? I assume from the above that B1 does not know about B2 (and vice versa)? Once connectivity between sites A and B restored, all unreplicated data will be replicated. There could be conflicts if there were changes on both sides during the split but majority of them are solved automatically by 389-ds. >6. If a client is installed with ipa-client-install using A1 and A1 gets >lost, does the client know, where it needs to connect (failover..)? IPA server which was used to enroll the host will be primary one (A1 in your example). There is failover in sssd.conf to use SRV records of the domain, and trying servers in the order returned by the SRV records. >7. Can I install slave (read-only) replicas so clients access them only >for queries and for changes (like pw change) they access master servers? No read-only replicas available for IPA. All replicas are read-write and propagate changes across replication paths as defined in replication agreements. All IPA servers are really masters, thus we have multi-master replication rather than master-slave. -- / Alexander Bokovoy From rmeggins at redhat.com Tue Nov 5 14:17:55 2013 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 05 Nov 2013 07:17:55 -0700 Subject: [Freeipa-users] ui login error and questions about replication In-Reply-To: <20131105130425.GE25335@redhat.com> References: <5278E564.6030403@martos.bme.hu> <20131105130425.GE25335@redhat.com> Message-ID: <5278FE13.6030401@redhat.com> On 11/05/2013 06:04 AM, Alexander Bokovoy wrote: > On Tue, 05 Nov 2013, Tamas Papp wrote: >> hi, >> >> The systems are uptodate F19 KVM guests. >> >> >> I'm trying to login the web ui with no success: >> >> "Your session has expired. Please re-login. >> >> To login with Kerberos, please make sure you have valid tickets >> (obtainable via kinit) and configured >> the browser >> correctly, then click Login. >> >> To login with username and password, enter them in the fields below then >> click Login." >> >> >> Then after a while something happens and it starts working. >> >> In logs: >> >> On the "primary" node: >> >> [05/Nov/2013:12:19:06 +0100] NSMMReplicationPlugin - >> agmt="cn=meToipa12.bpo.cxn" (ipa12:389): Replication bind with GSSAPI >> auth resumed >> >> >> On the "secondary" node: >> >> [05/Nov/2013:12:31:25 +0100] csngen_new_csn - Warning: too much time >> skew (-1658 secs). Current seqnum=3 >> [05/Nov/2013:12:45:33 +0100] csngen_new_csn - Warning: too much time >> skew (-811 secs). Current seqnum=a >> [05/Nov/2013:12:45:33 +0100] csngen_new_csn - Warning: too much time >> skew (-812 secs). Current seqnum=1 >> [05/Nov/2013:12:45:35 +0100] csngen_new_csn - Warning: too much time >> skew (-811 secs). Current seqnum=1 >> [05/Nov/2013:12:45:47 +0100] csngen_new_csn - Warning: too much time >> skew (-800 secs). Current seqnum=4 >> [05/Nov/2013:12:45:47 +0100] csngen_new_csn - Warning: too much time >> skew (-801 secs). Current seqnum=1 >> [05/Nov/2013:12:45:49 +0100] csngen_new_csn - Warning: too much time >> skew (-800 secs). Current seqnum=1 https://fedorahosted.org/389/ticket/47516 This has been fixed upstream and in some releases - to allow replication to proceed despite excessive clock skew - what is your 389-ds-base version and platform? >> >> >> Date shows up the same system time on both machines: >> >> Tue Nov 5 12:59:29 CET 2013 >> >> I called as primary the machine that was installed initially and >> secondary is the one that was deployed by replication. > Virtual Machines are known to have issues with keeping time in sync. > >> Finally, I have some questions:) >> >> 1. How can this happen, what's the problem? Is it something about the >> design, I screwed up something, or maybe the virtualization layer..? >> How can I avoid it and if it happens, how can I fix it immediately? > It is virtualization/time issue. > https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Virtualization_for_Desktops/2.2/html/Administration_Guide/chap-Virtualization-KVM_guest_timing_management.html > > >> 2. What is the difference between 'primary' and 'secondary'. What does >> happen, if the primary machine gets destroyed? > In IPA all replicas are the same, they only would differ by the paths > they sync with each other and by presence of integrated CA (if any). > > If you have deployed original IPA server with integrated CA, then your > other replicas better to have at least one with CA configured to allow > proper recovery in case primary one is destroyed. > > > >> 4. How many "master" can I use? > Technically there could be 65536 different masters in 389-ds replication > topology. > >> 5. If I have a network like this: >> >> A1______B1 >> A2 B2 >> >> A2 and B1,2 are replicated from A1 >> >> If the connection gets lost between A and B site, are B1 and 2 (and >> A1,2) replicated fine? > I assume from the above that B1 does not know about B2 (and vice versa)? > Once connectivity between sites A and B restored, all unreplicated data > will be replicated. There could be conflicts if there were changes on > both sides during the split but majority of them are solved > automatically by 389-ds. > >> 6. If a client is installed with ipa-client-install using A1 and A1 gets >> lost, does the client know, where it needs to connect (failover..)? > IPA server which was used to enroll the host will be primary one (A1 in > your example). There is failover in sssd.conf to use SRV records of the > domain, and trying servers in the order returned by the SRV records. > >> 7. Can I install slave (read-only) replicas so clients access them only >> for queries and for changes (like pw change) they access master servers? > No read-only replicas available for IPA. All replicas are read-write and > propagate changes across replication paths as defined in replication > agreements. All IPA servers are really masters, thus we have > multi-master replication rather than master-slave. > From tompos at martos.bme.hu Tue Nov 5 14:53:42 2013 From: tompos at martos.bme.hu (Tamas Papp) Date: Tue, 05 Nov 2013 15:53:42 +0100 Subject: [Freeipa-users] ui login error and questions about replication In-Reply-To: <5278FE13.6030401@redhat.com> References: <5278E564.6030403@martos.bme.hu> <20131105130425.GE25335@redhat.com> <5278FE13.6030401@redhat.com> Message-ID: <52790676.9080105@martos.bme.hu> On 11/05/2013 03:17 PM, Rich Megginson wrote: > > https://fedorahosted.org/389/ticket/47516 > > This has been fixed upstream and in some releases - to allow > replication to proceed despite excessive clock skew - what is your > 389-ds-base version and platform? What is the clock skewed? The date and time is the same on both machines. freeipa-admintools-3.3.2-1.fc19.x86_64 freeipa-client-3.3.2-1.fc19.x86_64 freeipa-python-3.3.2-1.fc19.x86_64 freeipa-server-3.3.2-1.fc19.x86_64 libipa_hbac-1.11.1-4.fc19.x86_64 libipa_hbac-python-1.11.1-4.fc19.x86_64 sssd-ipa-1.11.1-4.fc19.x86_64 389-ds-base-libs-1.3.1.12-1.fc19.x86_64 389-ds-base-1.3.1.12-1.fc19.x86_64 Linux ipa31.bph.cxn 3.11.6-201.fc19.x86_64 #1 SMP Sat Nov 2 14:09:09 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux Fedora 19. How can I fix it? Thanks, tamas From rmeggins at redhat.com Tue Nov 5 14:58:46 2013 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 05 Nov 2013 07:58:46 -0700 Subject: [Freeipa-users] ui login error and questions about replication In-Reply-To: <52790676.9080105@martos.bme.hu> References: <5278E564.6030403@martos.bme.hu> <20131105130425.GE25335@redhat.com> <5278FE13.6030401@redhat.com> <52790676.9080105@martos.bme.hu> Message-ID: <527907A6.9040809@redhat.com> On 11/05/2013 07:53 AM, Tamas Papp wrote: > On 11/05/2013 03:17 PM, Rich Megginson wrote: >> https://fedorahosted.org/389/ticket/47516 >> >> This has been fixed upstream and in some releases - to allow >> replication to proceed despite excessive clock skew - what is your >> 389-ds-base version and platform? > What is the clock skewed? The date and time is the same on both machines. VMs are notorious for having the clocks get out of sync - even temporarily. > > freeipa-admintools-3.3.2-1.fc19.x86_64 > freeipa-client-3.3.2-1.fc19.x86_64 > freeipa-python-3.3.2-1.fc19.x86_64 > freeipa-server-3.3.2-1.fc19.x86_64 > libipa_hbac-1.11.1-4.fc19.x86_64 > libipa_hbac-python-1.11.1-4.fc19.x86_64 > sssd-ipa-1.11.1-4.fc19.x86_64 > 389-ds-base-libs-1.3.1.12-1.fc19.x86_64 > 389-ds-base-1.3.1.12-1.fc19.x86_64 > > Linux ipa31.bph.cxn 3.11.6-201.fc19.x86_64 #1 SMP Sat Nov 2 14:09:09 UTC > 2013 x86_64 x86_64 x86_64 GNU/Linux > Fedora 19. > > > How can I fix it? ldapmodify -x -D "cn=directory manager" -W < > > Thanks, > tamas > From qwerty at melt.se Tue Nov 5 15:05:44 2013 From: qwerty at melt.se (EP) Date: Tue, 05 Nov 2013 16:05:44 +0100 Subject: [Freeipa-users] Requesting contact with users running PassSync AD -> FreeIPA Message-ID: <52790948.3080206@melt.se> Hi, I'm pushing to get password and user synchronization from AD to FreeIPA at the company I work for. Our windows administrators are very nervous about installing the PassSync service on their AD-controllers, and have asked me to provide a reference contact, meaning someone they could ask some questions about the service. I have asked Red Hat support about this, but they point me to their "upstream project". So would anyone in here be willing to answer (by email) a few questions and concerns that our windows admins have regarding synchronization from AD? Long shot, but worth a try :) Please give me a shout on qwerty at melt.se if you're willing to help out. Thanks! Best regards, EP From pablo at vdevices.com Tue Nov 5 15:06:44 2013 From: pablo at vdevices.com (Pablo Carranza) Date: Tue, 5 Nov 2013 09:06:44 -0600 Subject: [Freeipa-users] Got a minute to help a n00b w/IPA server on CentOS 6.4? Message-ID: Greetings! I only recently stumbled upon FreeIPA and am salivating at the mouth (sorry for the gross mental picture!) in excitement. Twice now, I've tried to install IPA server on a Centos 6.4 VPS at DigitalOcean; only to helplessly watch the install process hang at some point after executing sudo ipa-server-install. My 'Google skillz' are failing me in that I've only been able to find these tutorials (neither of which, unfortunately, address the issue I'm encountering): - http://www.howtoforge.com/installing-freeipa-with-replication - http://sgros.blogspot.com/2012/06/installing-freeipa-on-minimal-centos.html - http://www.server-world.info/en/note?os=CentOS_6&p=ipa 1.) Does anyone know of any good documentation out there on deploying IPA server on CentOS (or, is it not advisable to do such a thing)? I'm relatively 'green' in the Linux world and got started by diving into Ubuntu. 2.) Is it possible to run a production server with IPA server on Ubuntu? Since stumbling onto FreeIPA, I've finally started looking into Fedora. While Fedora looks very interesting, most of the Internet-chatter I've encountered seems to recommend CentOS over Fedora for (RedHat-alternative) production servers. 3.) Any reason why a production server could not have IPA server on Fedora? TIA! -Pablo vDevices.com | Providing Hosted IT Solutions for Lawyers & Other Mobile Professionals -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Tue Nov 5 15:14:54 2013 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 05 Nov 2013 08:14:54 -0700 Subject: [Freeipa-users] Requesting contact with users running PassSync AD -> FreeIPA In-Reply-To: <52790948.3080206@melt.se> References: <52790948.3080206@melt.se> Message-ID: <52790B6E.7060608@redhat.com> On 11/05/2013 08:05 AM, EP wrote: > Hi, > > I'm pushing to get password and user synchronization from AD to > FreeIPA at the company I work for. > > Our windows administrators are very nervous about installing the > PassSync service on their AD-controllers, and have asked me to provide > a reference contact, meaning someone they could ask some questions > about the service. Just send the questions to freeipa-users. I'm sure we would all be curious to see what the questions are. An existing user of PassSync might not want to be pulled into an open ended Q&A session and troubleshooting session, but would probably be willing to answer a few public questions. > > I have asked Red Hat support about this, but they point me to their > "upstream project". Are you a Red Hat Customer? If so, please contact me by direct email. I would like to follow up with you privately about the extent of your experience with support. > So would anyone in here be willing to answer (by email) a few > questions and concerns that our windows admins have regarding > synchronization from AD? Just send them to the freeipa-users list? > > > Long shot, but worth a try :) > > Please give me a shout on qwerty at melt.se if you're willing to help > out. Thanks! > > Best regards, EP > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From anton at kostenko.me Tue Nov 5 15:29:05 2013 From: anton at kostenko.me (=?UTF-8?B?0JDQvdGC0L7QvSDQmtC+0YHRgtC10L3QutC+?=) Date: Tue, 5 Nov 2013 19:29:05 +0400 Subject: [Freeipa-users] FreeIPA and AD, pass sync, different cn Message-ID: Hello everyone! Please, explain me a one thing. I have a that kind situation: In our company we have two domains - AD for everyone and FreeIPA for developers and servers. They have a different dn. Freeipa have dn=privatedomain,dn=loc, AD have dn=publicdomain,dn=com. But we have a same users login. Question: Can I sync password between AD and FreeIPA by password synchronization tool? --- With best regards, Many Thanks! Anton. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Tue Nov 5 15:36:00 2013 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 05 Nov 2013 08:36:00 -0700 Subject: [Freeipa-users] FreeIPA and AD, pass sync, different cn In-Reply-To: References: Message-ID: <52791060.5050402@redhat.com> On 11/05/2013 08:29 AM, ????? ???????? wrote: > Hello everyone! > Please, explain me a one thing. > I have a that kind situation: > In our company we have two domains - AD for everyone and FreeIPA for > developers and servers. They have a different dn. Freeipa have > dn=privatedomain,dn=loc, AD have dn=publicdomain,dn=com. > But we have a same users login. > Question: > Can I sync password between AD and FreeIPA by password synchronization > tool? Yes. > > --- > With best regards, > Many Thanks! > Anton. > > > _______________________________________________ > 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 qwerty at melt.se Tue Nov 5 15:45:45 2013 From: qwerty at melt.se (EP) Date: Tue, 5 Nov 2013 16:45:45 +0100 Subject: [Freeipa-users] Requesting contact with users running PassSync AD -> FreeIPA In-Reply-To: <52790B6E.7060608@redhat.com> References: <52790948.3080206@melt.se> <52790B6E.7060608@redhat.com> Message-ID: <1D629EDD-8065-4429-AFA2-D2A72D2F9489@melt.se> Hi, They had a phone session with Red Hat first line support, so they are feeling quite safe with the solution itself (in theory). What they're after now is more or less some end user testimonials... perhaps a few of you PassSync users out there could write a couple of lines about your experience with the product. Like how long you've used it, size if your organization, general good or bad experience... I believe that could calm the nervous minds of our AD admins :) //EP From rmeggins at redhat.com Tue Nov 5 15:53:21 2013 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 05 Nov 2013 08:53:21 -0700 Subject: [Freeipa-users] Requesting contact with users running PassSync AD -> FreeIPA In-Reply-To: <1D629EDD-8065-4429-AFA2-D2A72D2F9489@melt.se> References: <52790948.3080206@melt.se> <52790B6E.7060608@redhat.com> <1D629EDD-8065-4429-AFA2-D2A72D2F9489@melt.se> Message-ID: <52791471.9060003@redhat.com> On 11/05/2013 08:45 AM, EP wrote: > Hi, > > They had a phone session with Red Hat first line support, so they are feeling quite safe with the solution itself (in theory). > > What they're after now is more or less some end user testimonials... perhaps a few of you PassSync users out there could write a couple of lines about your experience with the product. Like how long you've used it, size if your organization, general good or bad experience... I believe that could calm the nervous minds of our AD admins :) Note: this is why the preferred solution going forward is cross domain trust between FreeIPA and AD - no passwords to sync, no packages to install on "precious" AD machines. > > //EP > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From simo at redhat.com Tue Nov 5 15:58:40 2013 From: simo at redhat.com (Simo Sorce) Date: Tue, 05 Nov 2013 10:58:40 -0500 Subject: [Freeipa-users] FreeIPA and AD, pass sync, different cn In-Reply-To: <52791060.5050402@redhat.com> References: <52791060.5050402@redhat.com> Message-ID: <1383667120.6607.83.camel@willson.li.ssimo.org> On Tue, 2013-11-05 at 08:36 -0700, Rich Megginson wrote: > On 11/05/2013 08:29 AM, ????? ???????? wrote: > > Question: > > Can I sync password between AD and FreeIPA by password > > synchronization tool? > > > Yes. To give a little bit more guidance, you may read on it here: http://docs.fedoraproject.org/en-US/Fedora/18/html-single/FreeIPA_Guide/index.html#active-directory Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Tue Nov 5 16:13:41 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 05 Nov 2013 11:13:41 -0500 Subject: [Freeipa-users] Got a minute to help a n00b w/IPA server on CentOS 6.4? In-Reply-To: References: Message-ID: <52791935.7090900@redhat.com> Pablo Carranza wrote: > Greetings! > > I only recently stumbled upon FreeIPA and am salivating at the mouth > (sorry for the gross mental picture!) in excitement. > > Twice now, I've tried to install IPA server on a Centos 6.4 VPS at > DigitalOcean > ; > only to helplessly watch the install process hang at some point after > executing sudo ipa-server-install. > > My 'Google skillz' are failing me in that I've only been able to find > these tutorials (neither of which, unfortunately, address the issue I'm > encountering): > > * http://www.howtoforge.com/installing-freeipa-with-replication > * http://sgros.blogspot.com/2012/06/installing-freeipa-on-minimal-centos.html > * http://www.server-world.info/en/note?os=CentOS_6&p=ipa > > 1.) Does anyone know of any good documentation out there on deploying > IPA server on CentOS (or, is it not advisable to do such a thing)? It should be fine, lots of folks do it. The RHEL documentation is probably your best bet. See the Identity Management Guide here, https://access.redhat.com/site/documentation/Red_Hat_Enterprise_Linux/?locale=en-US To diagnose the hanging installer we'd need to see the server install log, /var/log/ipaserver-install.log. > > I'm relatively 'green' in the Linux world and got started by diving into > Ubuntu. > > 2.) Is it possible to run a production server with IPA server on Ubuntu? > > Since stumbling onto FreeIPA, I've finally started looking into Fedora. > While Fedora looks very interesting, most of the Internet-chatter I've > encountered seems to recommend CentOS over Fedora for > (RedHat-alternative) production servers. No. The dependencies we need are not there yet, though it is being worked on. > > 3.) Any reason why a production server could not have IPA server on Fedora? It can work and some people have done it but Fedora moves quickly with a release every 6 months or so which is too fast moving for some. rob From dpal at redhat.com Tue Nov 5 16:54:46 2013 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 05 Nov 2013 11:54:46 -0500 Subject: [Freeipa-users] Requesting contact with users running PassSync AD -> FreeIPA In-Reply-To: <1D629EDD-8065-4429-AFA2-D2A72D2F9489@melt.se> References: <52790948.3080206@melt.se> <52790B6E.7060608@redhat.com> <1D629EDD-8065-4429-AFA2-D2A72D2F9489@melt.se> Message-ID: <527922D6.1010502@redhat.com> On 11/05/2013 10:45 AM, EP wrote: > Hi, > > They had a phone session with Red Hat first line support, so they are feeling quite safe with the solution itself (in theory). > > What they're after now is more or less some end user testimonials... perhaps a few of you PassSync users out there could write a couple of lines about your experience with the product. Like how long you've used it, size if your organization, general good or bad experience... I believe that could calm the nervous minds of our AD admins :) > > //EP > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users We find it extremely difficult to get such testimonials and the reason is that it is a part of the core security infra and people do not like to talk about it or not legally allowed to. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From qwerty at melt.se Tue Nov 5 19:05:40 2013 From: qwerty at melt.se (EP) Date: Tue, 5 Nov 2013 20:05:40 +0100 Subject: [Freeipa-users] Requesting contact with users running PassSync AD -> FreeIPA In-Reply-To: <527922D6.1010502@redhat.com> References: <52790948.3080206@melt.se> <52790B6E.7060608@redhat.com> <1D629EDD-8065-4429-AFA2-D2A72D2F9489@melt.se> <527922D6.1010502@redhat.com> Message-ID: <4929A617-9538-45E8-8C44-B57A26438ED7@melt.se> Thanks for your answers so far. A question about cross realm trusts though: This requires the AD servers to be available when doing a login via FreeIPA, right? Or is FreeIPA caching information from AD? We don't want Linux logins to be dependent on a windows server being available, that won't end well :) From sakodak at gmail.com Tue Nov 5 19:40:37 2013 From: sakodak at gmail.com (KodaK) Date: Tue, 5 Nov 2013 13:40:37 -0600 Subject: [Freeipa-users] Revisiting ILO Message-ID: I'm attempting to get HP ILO authenticating against IPA again. I've configured the user context in ILO as: cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com When ILO tries to connect, it sends the string: CN=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com Which, of course, doesn't exist. IPA uses uid=, but as far as I can tell I can't tell ILO to use a different username attribute. It doesn't even look like it's trying to use a username attribute. I've tried to force it to look for uid=jebalicki by using "uid=jebalicki" in the login field, but that fails too. The errors in the errors log look like this: [05/Nov/2013:13:22:05 -0600] ipalockout_preop - [file ipa_lockout.c, line 645]: Failed to retrieve entry "jebalicki": 32 [05/Nov/2013:13:22:05 -0600] ipalockout_postop - [file ipa_lockout.c, line 421]: Failed to retrieve entry "jebalicki": 32 [05/Nov/2013:13:22:05 -0600] ipalockout_preop - [file ipa_lockout.c, line 645]: Failed to retrieve entry "CN=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com": 32 [05/Nov/2013:13:22:05 -0600] ipalockout_postop - [file ipa_lockout.c, line 421]: Failed to retrieve entry "CN=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com": 32 [05/Nov/2013:13:22:05 -0600] ipalockout_preop - [file ipa_lockout.c, line 645]: Failed to retrieve entry "jebalicki": 32 [05/Nov/2013:13:22:05 -0600] ipalockout_postop - [file ipa_lockout.c, line 421]: Failed to retrieve entry "jebalicki": 32 [05/Nov/2013:13:22:05 -0600] ipalockout_preop - [file ipa_lockout.c, line 645]: Failed to retrieve entry "CN=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com": 32 [05/Nov/2013:13:22:05 -0600] ipalockout_postop - [file ipa_lockout.c, line 421]: Failed to retrieve entry "CN=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com": 32 [05/Nov/2013:13:22:05 -0600] ipalockout_preop - [file ipa_lockout.c, line 645]: Failed to retrieve entry "jebalicki": 32 [05/Nov/2013:13:22:05 -0600] ipalockout_postop - [file ipa_lockout.c, line 421]: Failed to retrieve entry "jebalicki": 32 [05/Nov/2013:13:22:05 -0600] ipalockout_preop - [file ipa_lockout.c, line 645]: Failed to retrieve entry "CN=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com": 32 [05/Nov/2013:13:22:05 -0600] ipalockout_postop - [file ipa_lockout.c, line 421]: Failed to retrieve entry "CN=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com": 32 [05/Nov/2013:13:27:39 -0600] ipalockout_preop - [file ipa_lockout.c, line 645]: Failed to retrieve entry "uid=jebalicki": 32 [05/Nov/2013:13:27:39 -0600] ipalockout_postop - [file ipa_lockout.c, line 421]: Failed to retrieve entry "uid=jebalicki": 32 [05/Nov/2013:13:27:39 -0600] ipalockout_preop - [file ipa_lockout.c, line 645]: Failed to retrieve entry "CN=uid=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com": 32 [05/Nov/2013:13:27:39 -0600] ipalockout_postop - [file ipa_lockout.c, line 421]: Failed to retrieve entry "CN=uid=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com": 32 [05/Nov/2013:13:27:39 -0600] ipalockout_preop - [file ipa_lockout.c, line 645]: Failed to retrieve entry "uid=jebalicki": 32 [05/Nov/2013:13:27:39 -0600] ipalockout_postop - [file ipa_lockout.c, line 421]: Failed to retrieve entry "uid=jebalicki": 32 [05/Nov/2013:13:27:39 -0600] ipalockout_preop - [file ipa_lockout.c, line 645]: Failed to retrieve entry "CN=uid=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com": 32 [05/Nov/2013:13:27:39 -0600] ipalockout_postop - [file ipa_lockout.c, line 421]: Failed to retrieve entry "CN=uid=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com": 32 [05/Nov/2013:13:27:39 -0600] ipalockout_preop - [file ipa_lockout.c, line 645]: Failed to retrieve entry "uid=jebalicki": 32 [05/Nov/2013:13:27:39 -0600] ipalockout_postop - [file ipa_lockout.c, line 421]: Failed to retrieve entry "uid=jebalicki": 32 [05/Nov/2013:13:27:39 -0600] ipalockout_preop - [file ipa_lockout.c, line 645]: Failed to retrieve entry "CN=uid=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com": 32 [05/Nov/2013:13:27:39 -0600] ipalockout_postop - [file ipa_lockout.c, line 421]: Failed to retrieve entry "CN=uid=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com": 32 And the access log looks like this: [05/Nov/2013:13:32:06 -0600] conn=214941 fd=438 slot=438 SSL connection from 10.200.10.192 to 10.200.16.170 [05/Nov/2013:13:32:06 -0600] conn=214941 SSL 256-bit AES [05/Nov/2013:13:32:06 -0600] conn=214941 op=0 BIND dn="uid=jebalicki" method=128 version=2 [05/Nov/2013:13:32:06 -0600] conn=214941 op=0 RESULT err=32 tag=97 nentries=0 etime=0 [05/Nov/2013:13:32:06 -0600] conn=214941 op=1 BIND dn="CN=uid=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com" method=128 version=2 [05/Nov/2013:13:32:07 -0600] conn=214941 op=1 RESULT err=32 tag=97 nentries=0 etime=1 [05/Nov/2013:13:32:07 -0600] conn=214941 op=2 UNBIND [05/Nov/2013:13:32:07 -0600] conn=214941 op=2 fd=438 closed - U1 [05/Nov/2013:13:32:07 -0600] conn=214942 fd=439 slot=439 SSL connection from 10.200.10.192 to 10.200.16.170 [05/Nov/2013:13:32:07 -0600] conn=214942 SSL 256-bit AES [05/Nov/2013:13:32:07 -0600] conn=214942 op=0 BIND dn="uid=jebalicki" method=128 version=2 [05/Nov/2013:13:32:07 -0600] conn=214942 op=0 RESULT err=32 tag=97 nentries=0 etime=0 [05/Nov/2013:13:32:07 -0600] conn=214942 op=1 UNBIND [05/Nov/2013:13:32:07 -0600] conn=214942 op=1 fd=439 closed - U1 [05/Nov/2013:13:32:07 -0600] conn=214943 fd=438 slot=438 SSL connection from 10.200.10.192 to 10.200.16.170 [05/Nov/2013:13:32:07 -0600] conn=214943 SSL 256-bit AES [05/Nov/2013:13:32:07 -0600] conn=214943 op=0 BIND dn="CN=uid=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com" method=128 version=2 [05/Nov/2013:13:32:07 -0600] conn=214943 op=0 RESULT err=32 tag=97 nentries=0 etime=0 [05/Nov/2013:13:32:07 -0600] conn=214943 op=1 UNBIND [05/Nov/2013:13:32:07 -0600] conn=214943 op=1 fd=438 closed - U1 Is there any way to force things on the IPA side? Can I automatically attach on the necessary components to the provided username? -------------- next part -------------- An HTML attachment was scrubbed... URL: From sakodak at gmail.com Tue Nov 5 19:51:03 2013 From: sakodak at gmail.com (KodaK) Date: Tue, 5 Nov 2013 13:51:03 -0600 Subject: [Freeipa-users] Revisiting ILO In-Reply-To: References: Message-ID: If I use the whole connection string: uid=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com I can authenticate. On Tue, Nov 5, 2013 at 1:40 PM, KodaK wrote: > I'm attempting to get HP ILO authenticating against IPA again. > > I've configured the user context in ILO as: > > cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com > > When ILO tries to connect, it sends the string: > > CN=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com > > Which, of course, doesn't exist. IPA uses uid=, but as far as I > can tell I can't tell ILO to use a different username attribute. It > doesn't even look like it's trying to use a username attribute. > > I've tried to force it to look for uid=jebalicki by using "uid=jebalicki" > in the login field, but that fails too. The errors in the errors log look > like this: > > > [05/Nov/2013:13:22:05 -0600] ipalockout_preop - [file ipa_lockout.c, line > 645]: Failed to retrieve entry "jebalicki": 32 > [05/Nov/2013:13:22:05 -0600] ipalockout_postop - [file ipa_lockout.c, line > 421]: Failed to retrieve entry "jebalicki": 32 > [05/Nov/2013:13:22:05 -0600] ipalockout_preop - [file ipa_lockout.c, line > 645]: Failed to retrieve entry > "CN=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com": 32 > [05/Nov/2013:13:22:05 -0600] ipalockout_postop - [file ipa_lockout.c, line > 421]: Failed to retrieve entry > "CN=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com": 32 > [05/Nov/2013:13:22:05 -0600] ipalockout_preop - [file ipa_lockout.c, line > 645]: Failed to retrieve entry "jebalicki": 32 > [05/Nov/2013:13:22:05 -0600] ipalockout_postop - [file ipa_lockout.c, line > 421]: Failed to retrieve entry "jebalicki": 32 > [05/Nov/2013:13:22:05 -0600] ipalockout_preop - [file ipa_lockout.c, line > 645]: Failed to retrieve entry > "CN=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com": 32 > [05/Nov/2013:13:22:05 -0600] ipalockout_postop - [file ipa_lockout.c, line > 421]: Failed to retrieve entry > "CN=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com": 32 > [05/Nov/2013:13:22:05 -0600] ipalockout_preop - [file ipa_lockout.c, line > 645]: Failed to retrieve entry "jebalicki": 32 > [05/Nov/2013:13:22:05 -0600] ipalockout_postop - [file ipa_lockout.c, line > 421]: Failed to retrieve entry "jebalicki": 32 > [05/Nov/2013:13:22:05 -0600] ipalockout_preop - [file ipa_lockout.c, line > 645]: Failed to retrieve entry > "CN=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com": 32 > [05/Nov/2013:13:22:05 -0600] ipalockout_postop - [file ipa_lockout.c, line > 421]: Failed to retrieve entry > "CN=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com": 32 > [05/Nov/2013:13:27:39 -0600] ipalockout_preop - [file ipa_lockout.c, line > 645]: Failed to retrieve entry "uid=jebalicki": 32 > [05/Nov/2013:13:27:39 -0600] ipalockout_postop - [file ipa_lockout.c, line > 421]: Failed to retrieve entry "uid=jebalicki": 32 > [05/Nov/2013:13:27:39 -0600] ipalockout_preop - [file ipa_lockout.c, line > 645]: Failed to retrieve entry > "CN=uid=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com": 32 > [05/Nov/2013:13:27:39 -0600] ipalockout_postop - [file ipa_lockout.c, line > 421]: Failed to retrieve entry > "CN=uid=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com": 32 > [05/Nov/2013:13:27:39 -0600] ipalockout_preop - [file ipa_lockout.c, line > 645]: Failed to retrieve entry "uid=jebalicki": 32 > [05/Nov/2013:13:27:39 -0600] ipalockout_postop - [file ipa_lockout.c, line > 421]: Failed to retrieve entry "uid=jebalicki": 32 > [05/Nov/2013:13:27:39 -0600] ipalockout_preop - [file ipa_lockout.c, line > 645]: Failed to retrieve entry > "CN=uid=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com": 32 > [05/Nov/2013:13:27:39 -0600] ipalockout_postop - [file ipa_lockout.c, line > 421]: Failed to retrieve entry > "CN=uid=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com": 32 > [05/Nov/2013:13:27:39 -0600] ipalockout_preop - [file ipa_lockout.c, line > 645]: Failed to retrieve entry "uid=jebalicki": 32 > [05/Nov/2013:13:27:39 -0600] ipalockout_postop - [file ipa_lockout.c, line > 421]: Failed to retrieve entry "uid=jebalicki": 32 > [05/Nov/2013:13:27:39 -0600] ipalockout_preop - [file ipa_lockout.c, line > 645]: Failed to retrieve entry > "CN=uid=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com": 32 > [05/Nov/2013:13:27:39 -0600] ipalockout_postop - [file ipa_lockout.c, line > 421]: Failed to retrieve entry > "CN=uid=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com": 32 > > And the access log looks like this: > > [05/Nov/2013:13:32:06 -0600] conn=214941 fd=438 slot=438 SSL connection > from 10.200.10.192 to 10.200.16.170 > [05/Nov/2013:13:32:06 -0600] conn=214941 SSL 256-bit AES > [05/Nov/2013:13:32:06 -0600] conn=214941 op=0 BIND dn="uid=jebalicki" > method=128 version=2 > [05/Nov/2013:13:32:06 -0600] conn=214941 op=0 RESULT err=32 tag=97 > nentries=0 etime=0 > [05/Nov/2013:13:32:06 -0600] conn=214941 op=1 BIND > dn="CN=uid=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com" > method=128 version=2 > [05/Nov/2013:13:32:07 -0600] conn=214941 op=1 RESULT err=32 tag=97 > nentries=0 etime=1 > [05/Nov/2013:13:32:07 -0600] conn=214941 op=2 UNBIND > [05/Nov/2013:13:32:07 -0600] conn=214941 op=2 fd=438 closed - U1 > [05/Nov/2013:13:32:07 -0600] conn=214942 fd=439 slot=439 SSL connection > from 10.200.10.192 to 10.200.16.170 > [05/Nov/2013:13:32:07 -0600] conn=214942 SSL 256-bit AES > [05/Nov/2013:13:32:07 -0600] conn=214942 op=0 BIND dn="uid=jebalicki" > method=128 version=2 > [05/Nov/2013:13:32:07 -0600] conn=214942 op=0 RESULT err=32 tag=97 > nentries=0 etime=0 > [05/Nov/2013:13:32:07 -0600] conn=214942 op=1 UNBIND > [05/Nov/2013:13:32:07 -0600] conn=214942 op=1 fd=439 closed - U1 > [05/Nov/2013:13:32:07 -0600] conn=214943 fd=438 slot=438 SSL connection > from 10.200.10.192 to 10.200.16.170 > [05/Nov/2013:13:32:07 -0600] conn=214943 SSL 256-bit AES > [05/Nov/2013:13:32:07 -0600] conn=214943 op=0 BIND > dn="CN=uid=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com" > method=128 version=2 > [05/Nov/2013:13:32:07 -0600] conn=214943 op=0 RESULT err=32 tag=97 > nentries=0 etime=0 > [05/Nov/2013:13:32:07 -0600] conn=214943 op=1 UNBIND > [05/Nov/2013:13:32:07 -0600] conn=214943 op=1 fd=438 closed - U1 > > Is there any way to force things on the IPA side? Can I automatically > attach on the necessary components to the provided username? > > -- The government is going to read our mail anyway, might as well make it tough for them. GPG Public key ID: B6A1A7C6 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tompos at martos.bme.hu Tue Nov 5 20:03:21 2013 From: tompos at martos.bme.hu (Tamas Papp) Date: Tue, 05 Nov 2013 21:03:21 +0100 Subject: [Freeipa-users] ui login error and questions about replication In-Reply-To: <527907A6.9040809@redhat.com> References: <5278E564.6030403@martos.bme.hu> <20131105130425.GE25335@redhat.com> <5278FE13.6030401@redhat.com> <52790676.9080105@martos.bme.hu> <527907A6.9040809@redhat.com> Message-ID: <52794F09.1060904@martos.bme.hu> On 11/05/2013 03:58 PM, Rich Megginson wrote: > On 11/05/2013 07:53 AM, Tamas Papp wrote: >> On 11/05/2013 03:17 PM, Rich Megginson wrote: >>> https://fedorahosted.org/389/ticket/47516 >>> >>> This has been fixed upstream and in some releases - to allow >>> replication to proceed despite excessive clock skew - what is your >>> 389-ds-base version and platform? >> What is the clock skewed? The date and time is the same on both >> machines. > > VMs are notorious for having the clocks get out of sync - even > temporarily. What do you mean by this? I definitely see the same time on the machines. Also I can see in the log, that the replication is resumed. There is no messages about the broken replication after the resume message. >> >> freeipa-admintools-3.3.2-1.fc19.x86_64 >> freeipa-client-3.3.2-1.fc19.x86_64 >> freeipa-python-3.3.2-1.fc19.x86_64 >> freeipa-server-3.3.2-1.fc19.x86_64 >> libipa_hbac-1.11.1-4.fc19.x86_64 >> libipa_hbac-python-1.11.1-4.fc19.x86_64 >> sssd-ipa-1.11.1-4.fc19.x86_64 >> 389-ds-base-libs-1.3.1.12-1.fc19.x86_64 >> 389-ds-base-1.3.1.12-1.fc19.x86_64 >> >> Linux ipa31.bph.cxn 3.11.6-201.fc19.x86_64 #1 SMP Sat Nov 2 14:09:09 UTC >> 2013 x86_64 x86_64 x86_64 GNU/Linux >> Fedora 19. >> >> >> How can I fix it? > > ldapmodify -x -D "cn=directory manager" -W < dn: cn=config > changetype: modify > replace: nsslapd-ignore-time-skew > nsslapd-ignore-time-skew: on > EOF > > Do this on all of your servers. I tried this, but no joy. Still not good:/ What I really don't understand, why I cannot login to ui (or to an installed client machine) if the replication doesn't work. Is it a normal behaviour? Thanks, tamas From rcritten at redhat.com Tue Nov 5 20:09:41 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 05 Nov 2013 15:09:41 -0500 Subject: [Freeipa-users] ui login error and questions about replication In-Reply-To: <52794F09.1060904@martos.bme.hu> References: <5278E564.6030403@martos.bme.hu> <20131105130425.GE25335@redhat.com> <5278FE13.6030401@redhat.com> <52790676.9080105@martos.bme.hu> <527907A6.9040809@redhat.com> <52794F09.1060904@martos.bme.hu> Message-ID: <52795085.5030307@redhat.com> Tamas Papp wrote: > > On 11/05/2013 03:58 PM, Rich Megginson wrote: >> On 11/05/2013 07:53 AM, Tamas Papp wrote: >>> On 11/05/2013 03:17 PM, Rich Megginson wrote: >>>> https://fedorahosted.org/389/ticket/47516 >>>> >>>> This has been fixed upstream and in some releases - to allow >>>> replication to proceed despite excessive clock skew - what is your >>>> 389-ds-base version and platform? >>> What is the clock skewed? The date and time is the same on both >>> machines. >> >> VMs are notorious for having the clocks get out of sync - even >> temporarily. > > What do you mean by this? > I definitely see the same time on the machines. > Also I can see in the log, that the replication is resumed. There is no > messages about the broken replication after the resume message. You see the same time NOW. The logs were reflecting a difference at that time. >>> >>> freeipa-admintools-3.3.2-1.fc19.x86_64 >>> freeipa-client-3.3.2-1.fc19.x86_64 >>> freeipa-python-3.3.2-1.fc19.x86_64 >>> freeipa-server-3.3.2-1.fc19.x86_64 >>> libipa_hbac-1.11.1-4.fc19.x86_64 >>> libipa_hbac-python-1.11.1-4.fc19.x86_64 >>> sssd-ipa-1.11.1-4.fc19.x86_64 >>> 389-ds-base-libs-1.3.1.12-1.fc19.x86_64 >>> 389-ds-base-1.3.1.12-1.fc19.x86_64 >>> >>> Linux ipa31.bph.cxn 3.11.6-201.fc19.x86_64 #1 SMP Sat Nov 2 14:09:09 UTC >>> 2013 x86_64 x86_64 x86_64 GNU/Linux >>> Fedora 19. >>> >>> >>> How can I fix it? >> >> ldapmodify -x -D "cn=directory manager" -W <> dn: cn=config >> changetype: modify >> replace: nsslapd-ignore-time-skew >> nsslapd-ignore-time-skew: on >> EOF >> >> Do this on all of your servers. > > I tried this, but no joy. Still not good:/ > > What I really don't understand, why I cannot login to ui (or to an > installed client machine) if the replication doesn't work. > Is it a normal behaviour? These issues are probably not related, unless perhaps the time skew is also throwing off the Kerberos tickets and/or session cache in the IPA framework. You didn't say how you were trying to log into the UI. Are you using Kerberos or the form-based authentication? rob From tompos at martos.bme.hu Tue Nov 5 20:20:23 2013 From: tompos at martos.bme.hu (Tamas Papp) Date: Tue, 05 Nov 2013 21:20:23 +0100 Subject: [Freeipa-users] ui login error and questions about replication In-Reply-To: <52795085.5030307@redhat.com> References: <5278E564.6030403@martos.bme.hu> <20131105130425.GE25335@redhat.com> <5278FE13.6030401@redhat.com> <52790676.9080105@martos.bme.hu> <527907A6.9040809@redhat.com> <52794F09.1060904@martos.bme.hu> <52795085.5030307@redhat.com> Message-ID: <52795307.3010602@martos.bme.hu> On 11/05/2013 09:09 PM, Rob Crittenden wrote: > Tamas Papp wrote: >> >> On 11/05/2013 03:58 PM, Rich Megginson wrote: >>> On 11/05/2013 07:53 AM, Tamas Papp wrote: >>>> On 11/05/2013 03:17 PM, Rich Megginson wrote: >>>>> https://fedorahosted.org/389/ticket/47516 >>>>> >>>>> This has been fixed upstream and in some releases - to allow >>>>> replication to proceed despite excessive clock skew - what is your >>>>> 389-ds-base version and platform? >>>> What is the clock skewed? The date and time is the same on both >>>> machines. >>> >>> VMs are notorious for having the clocks get out of sync - even >>> temporarily. >> >> What do you mean by this? >> I definitely see the same time on the machines. >> Also I can see in the log, that the replication is resumed. There is no >> messages about the broken replication after the resume message. > > You see the same time NOW. The logs were reflecting a difference at > that time. I saw the same, when the log messages appeared. Is there a way to get the time it sees from the other side? >> I tried this, but no joy. Still not good:/ >> >> What I really don't understand, why I cannot login to ui (or to an >> installed client machine) if the replication doesn't work. >> Is it a normal behaviour? > > These issues are probably not related, unless perhaps the time skew is > also throwing off the Kerberos tickets and/or session cache in the IPA > framework. > > You didn't say how you were trying to log into the UI. Are you using > Kerberos or the form-based authentication? Latter. There is no kerberos configured on my computer. But I've also tried with ssh on a normal computer. Both failed. tamas From rmeggins at redhat.com Tue Nov 5 20:25:26 2013 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 05 Nov 2013 13:25:26 -0700 Subject: [Freeipa-users] ui login error and questions about replication In-Reply-To: <52794F09.1060904@martos.bme.hu> References: <5278E564.6030403@martos.bme.hu> <20131105130425.GE25335@redhat.com> <5278FE13.6030401@redhat.com> <52790676.9080105@martos.bme.hu> <527907A6.9040809@redhat.com> <52794F09.1060904@martos.bme.hu> Message-ID: <52795436.7040406@redhat.com> On 11/05/2013 01:03 PM, Tamas Papp wrote: > On 11/05/2013 03:58 PM, Rich Megginson wrote: >> On 11/05/2013 07:53 AM, Tamas Papp wrote: >>> On 11/05/2013 03:17 PM, Rich Megginson wrote: >>>> https://fedorahosted.org/389/ticket/47516 >>>> >>>> This has been fixed upstream and in some releases - to allow >>>> replication to proceed despite excessive clock skew - what is your >>>> 389-ds-base version and platform? >>> What is the clock skewed? The date and time is the same on both >>> machines. >> VMs are notorious for having the clocks get out of sync - even >> temporarily. > What do you mean by this? > I definitely see the same time on the machines. > Also I can see in the log, that the replication is resumed. There is no > messages about the broken replication after the resume message. > >>> freeipa-admintools-3.3.2-1.fc19.x86_64 >>> freeipa-client-3.3.2-1.fc19.x86_64 >>> freeipa-python-3.3.2-1.fc19.x86_64 >>> freeipa-server-3.3.2-1.fc19.x86_64 >>> libipa_hbac-1.11.1-4.fc19.x86_64 >>> libipa_hbac-python-1.11.1-4.fc19.x86_64 >>> sssd-ipa-1.11.1-4.fc19.x86_64 >>> 389-ds-base-libs-1.3.1.12-1.fc19.x86_64 >>> 389-ds-base-1.3.1.12-1.fc19.x86_64 >>> >>> Linux ipa31.bph.cxn 3.11.6-201.fc19.x86_64 #1 SMP Sat Nov 2 14:09:09 UTC >>> 2013 x86_64 x86_64 x86_64 GNU/Linux >>> Fedora 19. >>> >>> >>> How can I fix it? >> ldapmodify -x -D "cn=directory manager" -W <> dn: cn=config >> changetype: modify >> replace: nsslapd-ignore-time-skew >> nsslapd-ignore-time-skew: on >> EOF >> >> Do this on all of your servers. > I tried this, but no joy. Still not good:/ Can you describe the exact steps you took, on all replicas? > > What I really don't understand, why I cannot login to ui (or to an > installed client machine) if the replication doesn't work. > Is it a normal behaviour? > > > Thanks, > tamas From tompos at martos.bme.hu Tue Nov 5 22:57:56 2013 From: tompos at martos.bme.hu (Tamas Papp) Date: Tue, 05 Nov 2013 23:57:56 +0100 Subject: [Freeipa-users] ui login error and questions about replication In-Reply-To: <52795307.3010602@martos.bme.hu> References: <5278E564.6030403@martos.bme.hu> <20131105130425.GE25335@redhat.com> <5278FE13.6030401@redhat.com> <52790676.9080105@martos.bme.hu> <527907A6.9040809@redhat.com> <52794F09.1060904@martos.bme.hu> <52795085.5030307@redhat.com> <52795307.3010602@martos.bme.hu> Message-ID: <527977F4.2060708@martos.bme.hu> On 11/05/2013 09:20 PM, Tamas Papp wrote: > On 11/05/2013 09:09 PM, Rob Crittenden wrote: >> Tamas Papp wrote: >>> On 11/05/2013 03:58 PM, Rich Megginson wrote: >>>> On 11/05/2013 07:53 AM, Tamas Papp wrote: >>>>> On 11/05/2013 03:17 PM, Rich Megginson wrote: >>>>>> https://fedorahosted.org/389/ticket/47516 >>>>>> >>>>>> This has been fixed upstream and in some releases - to allow >>>>>> replication to proceed despite excessive clock skew - what is your >>>>>> 389-ds-base version and platform? >>>>> What is the clock skewed? The date and time is the same on both >>>>> machines. >>>> VMs are notorious for having the clocks get out of sync - even >>>> temporarily. >>> What do you mean by this? >>> I definitely see the same time on the machines. >>> Also I can see in the log, that the replication is resumed. There is no >>> messages about the broken replication after the resume message. >> You see the same time NOW. The logs were reflecting a difference at >> that time. > I saw the same, when the log messages appeared. > Is there a way to get the time it sees from the other side? > > > >>> I tried this, but no joy. Still not good:/ >>> >>> What I really don't understand, why I cannot login to ui (or to an >>> installed client machine) if the replication doesn't work. >>> Is it a normal behaviour? >> These issues are probably not related, unless perhaps the time skew is >> also throwing off the Kerberos tickets and/or session cache in the IPA >> framework. >> >> You didn't say how you were trying to log into the UI. Are you using >> Kerberos or the form-based authentication? > Latter. > There is no kerberos configured on my computer. > But I've also tried with ssh on a normal computer. > Both failed. Recently I'm able to login to the UI. I made couple of changes, but probably this was the tricky one: One of the host machine was configured to UTC. So I changed the VM configuration as well: From to Before this change the 'RTC time:' line was lacking from the output of timedatectl and after the VM reboot the default time was wrong (though it could be fixed by ntpdate easily). After reboot it seems to be working, but: [05/Nov/2013:23:33:24 +0100] csngen_new_csn - Warning: too much time skew (-2852 secs). Current seqnum=1 [05/Nov/2013:23:33:24 +0100] NSMMReplicationPlugin - agmt="cn=meToipa12.bpo.cxn" (ipa12:389): Replication bind with GSSAPI auth resumed [05/Nov/2013:23:33:24 +0100] csngen_new_csn - Warning: too much time skew (-2853 secs). Current seqnum=1 [05/Nov/2013:23:33:25 +0100] csngen_new_csn - Warning: too much time skew (-2853 secs). Current seqnum=1 [[05/Nov/2013:23:33:51 +0100] csngen_new_csn - Warning: too much time skew (-2828 secs). Current seqnum=1 [05/Nov/2013:23:33:51 +0100] csngen_new_csn - Warning: too much time skew (-2829 secs). Current seqnum=1 [05/Nov/2013:23:33:51 +0100] csngen_new_csn - Warning: too much time skew (-2830 secs). Current seqnum=1 [05/Nov/2013:23:33:53 +0100] csngen_new_csn - Warning: too much time skew (-2829 secs). Current seqnum=1 [05/Nov/2013:23:35:14 +0100] csngen_new_csn - Warning: too much time skew (-2749 secs). Current seqnum=1 [05/Nov/2013:23:35:14 +0100] csngen_new_csn - Warning: too much time skew (-2750 secs). Current seqnum=1 [05/Nov/2013:23:35:23 +0100] csngen_new_csn - Warning: too much time skew (-2742 secs). Current seqnum=1 [05/Nov/2013:23:35:23 +0100] csngen_new_csn - Warning: too much time skew (-2743 secs). Current seqnum=1 # ldapsearch -x -D "cn=directory manager" -W |grep -i nsslapd-ignore-time-skew Enter LDAP Password: No I don't understand, why it was resumed and why it is working in spite of skewed time. And still I don't understand, why I cannot login, when the replication is not working. tamas From tompos at martos.bme.hu Tue Nov 5 23:23:33 2013 From: tompos at martos.bme.hu (Tamas Papp) Date: Wed, 06 Nov 2013 00:23:33 +0100 Subject: [Freeipa-users] ui login error and questions about replication In-Reply-To: <52795436.7040406@redhat.com> References: <5278E564.6030403@martos.bme.hu> <20131105130425.GE25335@redhat.com> <5278FE13.6030401@redhat.com> <52790676.9080105@martos.bme.hu> <527907A6.9040809@redhat.com> <52794F09.1060904@martos.bme.hu> <52795436.7040406@redhat.com> Message-ID: <52797DF5.6050701@martos.bme.hu> On 11/05/2013 09:25 PM, Rich Megginson wrote: > On 11/05/2013 01:03 PM, Tamas Papp wrote: >> On 11/05/2013 03:58 PM, Rich Megginson wrote: >>> On 11/05/2013 07:53 AM, Tamas Papp wrote: >>>> On 11/05/2013 03:17 PM, Rich Megginson wrote: >>>>> https://fedorahosted.org/389/ticket/47516 >>>>> >>>>> This has been fixed upstream and in some releases - to allow >>>>> replication to proceed despite excessive clock skew - what is your >>>>> 389-ds-base version and platform? >>>> What is the clock skewed? The date and time is the same on both >>>> machines. >>> VMs are notorious for having the clocks get out of sync - even >>> temporarily. >> What do you mean by this? >> I definitely see the same time on the machines. >> Also I can see in the log, that the replication is resumed. There is no >> messages about the broken replication after the resume message. >> >>>> freeipa-admintools-3.3.2-1.fc19.x86_64 >>>> freeipa-client-3.3.2-1.fc19.x86_64 >>>> freeipa-python-3.3.2-1.fc19.x86_64 >>>> freeipa-server-3.3.2-1.fc19.x86_64 >>>> libipa_hbac-1.11.1-4.fc19.x86_64 >>>> libipa_hbac-python-1.11.1-4.fc19.x86_64 >>>> sssd-ipa-1.11.1-4.fc19.x86_64 >>>> 389-ds-base-libs-1.3.1.12-1.fc19.x86_64 >>>> 389-ds-base-1.3.1.12-1.fc19.x86_64 >>>> >>>> Linux ipa31.bph.cxn 3.11.6-201.fc19.x86_64 #1 SMP Sat Nov 2 >>>> 14:09:09 UTC >>>> 2013 x86_64 x86_64 x86_64 GNU/Linux >>>> Fedora 19. >>>> >>>> >>>> How can I fix it? >>> ldapmodify -x -D "cn=directory manager" -W <>> dn: cn=config >>> changetype: modify >>> replace: nsslapd-ignore-time-skew >>> nsslapd-ignore-time-skew: on >>> EOF >>> >>> Do this on all of your servers. >> I tried this, but no joy. Still not good:/ > > Can you describe the exact steps you took, on all replicas? I created ldif files: # cat replication_ignore-time-skew.ldif dn: cn=config changetype: modify replace: nsslapd-ignore-time-skew nsslapd-ignore-time-skew: on Then: $ ldapmodify -x -D "cn=directory manager" -W -f replication_ignore-time-skew.ldif But I don't see the changes: # ldapsearch -x|grep -i ignore # Probably you realized, I'm not an ldap expert:) But I assume it's because it doesn't exist right now, therefore it should be add ot modify? I don't wan't to try it now, because currently it's working. Maybe when it gets fail again. Thanks, tamas From tompos at martos.bme.hu Tue Nov 5 23:34:39 2013 From: tompos at martos.bme.hu (Tamas Papp) Date: Wed, 06 Nov 2013 00:34:39 +0100 Subject: [Freeipa-users] ui login error and questions about replication In-Reply-To: <527907A6.9040809@redhat.com> References: <5278E564.6030403@martos.bme.hu> <20131105130425.GE25335@redhat.com> <5278FE13.6030401@redhat.com> <52790676.9080105@martos.bme.hu> <527907A6.9040809@redhat.com> Message-ID: <5279808F.5030609@martos.bme.hu> On 11/05/2013 03:58 PM, Rich Megginson wrote: > On 11/05/2013 07:53 AM, Tamas Papp wrote: >> On 11/05/2013 03:17 PM, Rich Megginson wrote: >>> https://fedorahosted.org/389/ticket/47516 >>> >>> This has been fixed upstream and in some releases - to allow >>> replication to proceed despite excessive clock skew - what is your >>> 389-ds-base version and platform? >> What is the clock skewed? The date and time is the same on both >> machines. > > VMs are notorious for having the clocks get out of sync - even > temporarily. Eventually you were right, it looks, that the problem is related to the virtualization, thanks for the tip. Although I wouldn't say, it's because of messy VMs. It definitely must be a software bug or misconfiguration, otherwise a VM should always looks the same as a bare metal machine. Actually in my specific case I don't see the reason, why it is working with and not with if the time in the VM synchronized after bootup. It looks a software bug to me. But using UTC on (only) one machine is definitely a misconfiguration:) Thanks, tamas From tompos at martos.bme.hu Tue Nov 5 23:48:50 2013 From: tompos at martos.bme.hu (Tamas Papp) Date: Wed, 06 Nov 2013 00:48:50 +0100 Subject: [Freeipa-users] ui login error and questions about replication In-Reply-To: <5278FE13.6030401@redhat.com> References: <5278E564.6030403@martos.bme.hu> <20131105130425.GE25335@redhat.com> <5278FE13.6030401@redhat.com> Message-ID: <527983E2.8000708@martos.bme.hu> On 11/05/2013 03:17 PM, Rich Megginson wrote: > >>> 2. What is the difference between 'primary' and 'secondary'. What does >>> happen, if the primary machine gets destroyed? >> In IPA all replicas are the same, they only would differ by the paths >> they sync with each other and by presence of integrated CA (if any). Do I need CA in normal cases or is it just an additional and optional service? In other words is this CA the same as used by replicas and clients and the UI..etc? >> If you have deployed original IPA server with integrated CA, then your >> other replicas better to have at least one with CA configured to allow >> proper recovery in case primary one is destroyed. Is there any caveats to not deploy CA on all replicas as a simples solution? >>> 4. How many "master" can I use? >> Technically there could be 65536 different masters in 389-ds replication >> topology. Perfect! >> >>> 5. If I have a network like this: >>> >>> A1______B1 >>> A2 B2 >>> >>> A2 and B1,2 are replicated from A1 >>> >>> If the connection gets lost between A and B site, are B1 and 2 (and >>> A1,2) replicated fine? >> I assume from the above that B1 does not know about B2 (and vice versa)? Well, that is actually one of the questions. B1 and B2 are on the same sites and failover nodes from point of view of clients. >> Once connectivity between sites A and B restored, all unreplicated data >> will be replicated. There could be conflicts if there were changes on >> both sides during the split but majority of them are solved >> automatically by 389-ds. The main question is that B1 and B2 are not replicated to each other automatically? What about the case if A1 -- replication -- A2 --- replication --- B1 -- replication -- B2 If B1 gets destroyed, how B2 and A2 (and A1) gets synchronized? Especially automatically...? Is there such a failover configuration? >>> 6. If a client is installed with ipa-client-install using A1 and A1 >>> gets >>> lost, does the client know, where it needs to connect (failover..)? >> IPA server which was used to enroll the host will be primary one (A1 in >> your example). There is failover in sssd.conf to use SRV records of the >> domain, and trying servers in the order returned by the SRV records. Ahh. Then if I use external DNS, I need to configure these srv records manually, that's all, right? >>> 7. Can I install slave (read-only) replicas so clients access them only >>> for queries and for changes (like pw change) they access master >>> servers? >> No read-only replicas available for IPA. All replicas are read-write and >> propagate changes across replication paths as defined in replication >> agreements. All IPA servers are really masters, thus we have >> multi-master replication rather than master-slave. Perfect, thanks for the clarification! Thanks, tamas From rmeggins at redhat.com Wed Nov 6 01:07:35 2013 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 05 Nov 2013 18:07:35 -0700 Subject: [Freeipa-users] ui login error and questions about replication In-Reply-To: <5279808F.5030609@martos.bme.hu> References: <5278E564.6030403@martos.bme.hu> <20131105130425.GE25335@redhat.com> <5278FE13.6030401@redhat.com> <52790676.9080105@martos.bme.hu> <527907A6.9040809@redhat.com> <5279808F.5030609@martos.bme.hu> Message-ID: <52799657.9070406@redhat.com> On 11/05/2013 04:34 PM, Tamas Papp wrote: > On 11/05/2013 03:58 PM, Rich Megginson wrote: >> On 11/05/2013 07:53 AM, Tamas Papp wrote: >>> On 11/05/2013 03:17 PM, Rich Megginson wrote: >>>> https://fedorahosted.org/389/ticket/47516 >>>> >>>> This has been fixed upstream and in some releases - to allow >>>> replication to proceed despite excessive clock skew - what is your >>>> 389-ds-base version and platform? >>> What is the clock skewed? The date and time is the same on both >>> machines. >> VMs are notorious for having the clocks get out of sync - even >> temporarily. > Eventually you were right, it looks, that the problem is related to the > virtualization, thanks for the tip. > > Although I wouldn't say, it's because of messy VMs. It definitely must > be a software bug or misconfiguration, otherwise a VM should always > looks the same as a bare metal machine. > > Actually in my specific case I don't see the reason, why it is working > with and not with if > the time in the VM synchronized after bootup. You can file a ticket. > It looks a software bug to me. But using UTC on (only) one machine is > definitely a misconfiguration:) > > > Thanks, > tamas From rmeggins at redhat.com Wed Nov 6 01:08:38 2013 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 05 Nov 2013 18:08:38 -0700 Subject: [Freeipa-users] ui login error and questions about replication In-Reply-To: <52797DF5.6050701@martos.bme.hu> References: <5278E564.6030403@martos.bme.hu> <20131105130425.GE25335@redhat.com> <5278FE13.6030401@redhat.com> <52790676.9080105@martos.bme.hu> <527907A6.9040809@redhat.com> <52794F09.1060904@martos.bme.hu> <52795436.7040406@redhat.com> <52797DF5.6050701@martos.bme.hu> Message-ID: <52799696.80308@redhat.com> On 11/05/2013 04:23 PM, Tamas Papp wrote: > On 11/05/2013 09:25 PM, Rich Megginson wrote: >> On 11/05/2013 01:03 PM, Tamas Papp wrote: >>> On 11/05/2013 03:58 PM, Rich Megginson wrote: >>>> On 11/05/2013 07:53 AM, Tamas Papp wrote: >>>>> On 11/05/2013 03:17 PM, Rich Megginson wrote: >>>>>> https://fedorahosted.org/389/ticket/47516 >>>>>> >>>>>> This has been fixed upstream and in some releases - to allow >>>>>> replication to proceed despite excessive clock skew - what is your >>>>>> 389-ds-base version and platform? >>>>> What is the clock skewed? The date and time is the same on both >>>>> machines. >>>> VMs are notorious for having the clocks get out of sync - even >>>> temporarily. >>> What do you mean by this? >>> I definitely see the same time on the machines. >>> Also I can see in the log, that the replication is resumed. There is no >>> messages about the broken replication after the resume message. >>> >>>>> freeipa-admintools-3.3.2-1.fc19.x86_64 >>>>> freeipa-client-3.3.2-1.fc19.x86_64 >>>>> freeipa-python-3.3.2-1.fc19.x86_64 >>>>> freeipa-server-3.3.2-1.fc19.x86_64 >>>>> libipa_hbac-1.11.1-4.fc19.x86_64 >>>>> libipa_hbac-python-1.11.1-4.fc19.x86_64 >>>>> sssd-ipa-1.11.1-4.fc19.x86_64 >>>>> 389-ds-base-libs-1.3.1.12-1.fc19.x86_64 >>>>> 389-ds-base-1.3.1.12-1.fc19.x86_64 >>>>> >>>>> Linux ipa31.bph.cxn 3.11.6-201.fc19.x86_64 #1 SMP Sat Nov 2 >>>>> 14:09:09 UTC >>>>> 2013 x86_64 x86_64 x86_64 GNU/Linux >>>>> Fedora 19. >>>>> >>>>> >>>>> How can I fix it? >>>> ldapmodify -x -D "cn=directory manager" -W <>>> dn: cn=config >>>> changetype: modify >>>> replace: nsslapd-ignore-time-skew >>>> nsslapd-ignore-time-skew: on >>>> EOF >>>> >>>> Do this on all of your servers. >>> I tried this, but no joy. Still not good:/ >> Can you describe the exact steps you took, on all replicas? > I created ldif files: > > # cat replication_ignore-time-skew.ldif > dn: cn=config > changetype: modify > replace: nsslapd-ignore-time-skew > nsslapd-ignore-time-skew: on > > Then: > > $ ldapmodify -x -D "cn=directory manager" -W -f > replication_ignore-time-skew.ldif > > > > But I don't see the changes: > > # ldapsearch -x|grep -i ignore ldapsearch -x -D "cn=directory manager" -W -s base -b cn=config 'objectclass=*' nsslapd-ignore-time-skew > # > > Probably you realized, I'm not an ldap expert:) > But I assume it's because it doesn't exist right now, therefore it > should be add ot modify? It is always ok to do a changetype: modify replace > > I don't wan't to try it now, because currently it's working. Maybe when > it gets fail again. Ok. > > > Thanks, > tamas From rcritten at redhat.com Wed Nov 6 03:16:56 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 05 Nov 2013 22:16:56 -0500 Subject: [Freeipa-users] ui login error and questions about replication In-Reply-To: <527983E2.8000708@martos.bme.hu> References: <5278E564.6030403@martos.bme.hu> <20131105130425.GE25335@redhat.com> <5278FE13.6030401@redhat.com> <527983E2.8000708@martos.bme.hu> Message-ID: <5279B4A8.3020802@redhat.com> Tamas Papp wrote: > > On 11/05/2013 03:17 PM, Rich Megginson wrote: >> >>>> 2. What is the difference between 'primary' and 'secondary'. What does >>>> happen, if the primary machine gets destroyed? >>> In IPA all replicas are the same, they only would differ by the paths >>> they sync with each other and by presence of integrated CA (if any). > > Do I need CA in normal cases or is it just an additional and optional > service? In other words is this CA the same as used by replicas and > clients and the UI..etc? Yes and since you are planning for replication you should plan to have at least one of the replica have a CA on it as well to avoid a single point of failure. > >>> If you have deployed original IPA server with integrated CA, then your >>> other replicas better to have at least one with CA configured to allow >>> proper recovery in case primary one is destroyed. > > Is there any caveats to not deploy CA on all replicas as a simples solution? You don't need a CA on every single replica, but you probably want at least two. > >>>> 4. How many "master" can I use? >>> Technically there could be 65536 different masters in 389-ds replication >>> topology. > > Perfect! The 389-ds team has fully QA'd 20 masters at a time, so keep that in mind. Also, replication is not free. It requires space to store the changes to send out, CPU time to calculate whom to send what and network bandwidth to share the data. Each master you add increases this workload. Not to mention any administrative burden of running a lot of masters. > >>> >>>> 5. If I have a network like this: >>>> >>>> A1______B1 >>>> A2 B2 >>>> >>>> A2 and B1,2 are replicated from A1 >>>> >>>> If the connection gets lost between A and B site, are B1 and 2 (and >>>> A1,2) replicated fine? >>> I assume from the above that B1 does not know about B2 (and vice versa)? > > Well, that is actually one of the questions. B1 and B2 are on the same > sites and failover nodes from point of view of clients. You can manage the replication topology with ipa-replica-manage connect and disconnect. So if you want B1 and B2 connected you can do that. > >>> Once connectivity between sites A and B restored, all unreplicated data >>> will be replicated. There could be conflicts if there were changes on >>> both sides during the split but majority of them are solved >>> automatically by 389-ds. > > The main question is that B1 and B2 are not replicated to each other > automatically? What about the case if > > A1 -- replication -- A2 --- replication --- B1 -- replication -- B2 > > If B1 gets destroyed, how B2 and A2 (and A1) gets synchronized? > Especially automatically...? > Is there such a failover configuration? No, the masters only replicate to the ones you tell them to, so if B1 went away forever then B2 would never get any other updates unless you explicitly made a connection to A1 or A2. > >>>> 6. If a client is installed with ipa-client-install using A1 and A1 >>>> gets >>>> lost, does the client know, where it needs to connect (failover..)? >>> IPA server which was used to enroll the host will be primary one (A1 in >>> your example). There is failover in sssd.conf to use SRV records of the >>> domain, and trying servers in the order returned by the SRV records. > > Ahh. Then if I use external DNS, I need to configure these srv records > manually, that's all, right? Right. > >>>> 7. Can I install slave (read-only) replicas so clients access them only >>>> for queries and for changes (like pw change) they access master >>>> servers? >>> No read-only replicas available for IPA. All replicas are read-write and >>> propagate changes across replication paths as defined in replication >>> agreements. All IPA servers are really masters, thus we have >>> multi-master replication rather than master-slave. > > > Perfect, thanks for the clarification! > > Thanks, > tamas > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > From william.leese at meltwater.com Wed Nov 6 05:32:42 2013 From: william.leese at meltwater.com (William Leese) Date: Wed, 6 Nov 2013 14:32:42 +0900 Subject: [Freeipa-users] External CA Message-ID: Hi, Trying to install freeIPA and have it a sub-ca of an existing one. Sadly I'm not getting anywhere. The version I have installed: ipa-server-3.0.0-26.el6_4.4.x86_64 This is what I run: ipa-server-install -U -a testtest -p testtest --external_cert_file=/root/server.pem --external_ca_file=/root/cacert.pem -p testtest -P testtest -r MELTWATER.COM Which runs this as part of the process: /usr/bin/pkisilent ConfigureCA -cs_hostname vagrant-centos-6.meltwater.com-cs_port 9445 -client_certdb_dir /tmp/tmp-bOrwSu -client_certdb_pwd testtest -preop_pin 4hdia3IvPvf27Qo7kBbO -domain_name IPA -admin_user admin -admin_email root at localhost -admin_password testtest -agent_name ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa -agent_cert_subject CN=ipa-ca-agent,O=MELTWATER.COM -ldap_host vagrant-centos-6.meltwater.com-ldap_port 7389 -bind_dn cn="Directory Manager" -bind_password testtest -base_dn o=ipaca -db_name ipaca -key_size 2048 -key_type rsa -key_algorithm SHA256withRSA -save_p12 true -backup_pwd testtest -subsystem_name pki-cad -token_name internal -ca_subsystem_cert_subject_name "CN=CA Subsystem,O= MELTWATER.COM" -ca_subsystem_cert_subject_name "CN=CA Subsystem,O= MELTWATER.COM" -ca_ocsp_cert_subject_name "CN=OCSP Subsystem,O=MELTWATER.COM" -ca_server_cert_subject_name CN=vagrant-centos-6.meltwater.com,O= MELTWATER.COM -ca_audit_signing_cert_subject_name "CN=CA Audit,O= MELTWATER.COM" -ca_sign_cert_subject_name "CN=Certificate Authority,O= MELTWATER.COM" -external true -ext_ca_cert_file /root/server.pem -ext_ca_cert_chain_file /root/cacert.pem All this results in this in the log: Failed to create pkcs12 file. [snip] Error in BackupPanel(): updateStatus value is null ERROR: ConfigureCA: BackupPanel() failure ERROR: unable to create CA Interestingly adding the option -save_p12 false to the pkisilent command above results in: importCert string: importing with nickname: ipa-ca-agent Already logged into to DB ERROR:exception importing cert Security library failed to decode certificate package: (-8183) security library: improperly formatted DER-encoded message. ERROR: AdminCertImportPanel() during cert import ERROR: ConfigureCA: AdminCertImportPanel() failure ERROR: unable to create CA While the option change seemed innocent, I honestly don't know if its crucial to the install or not. Anyhow, things don't really progress anyway. I followed the documentation by signing the /root/ipa.csr with a test, internal CA but somehow I can't get the install to proceed. [root at vagrant-centos-6 CA]# cat /root/server.pem Certificate: Data: Version: 3 (0x2) Serial Number: 2 (0x2) Signature Algorithm: sha1WithRSAEncryption Issuer: C=JP, ST=TK, L=TKK, O=MW, OU=ops, CN=vagrant.localdomain/emailAddress=t at t.com Validity Not Before: Nov 6 05:12:09 2013 GMT Not After : Nov 6 05:12:09 2014 GMT Subject: O=MELTWATER.COM, CN=Certificate Authority [snip] -----BEGIN CERTIFICATE----- MIIDfDCCAmSgAwIBAgIBAjANBgkqhkiG9w0BAQUFADB5MQswCQYDVQQGEwJKUDEL MAkGA1UECAwCVEsxDDAKBgNVBAcMA1RLSzELMAkGA1UECgwCTVcxDDAKBgNVBAsM A29wczEcMBoGA1UEAwwTdmFncmFudC5sb2NhbGRvbWFpbjEWMBQGCSqGSIb3DQEJ [snip] [root at vagrant-centos-6 CA]# cat /root/cacert.pem -----BEGIN CERTIFICATE----- MIIDxTCCAq2gAwIBAgIJALIzKeNrwx2lMA0GCSqGSIb3DQEBBQUAMHkxCzAJBgNV BAYTAkpQMQswCQYDVQQIDAJUSzEMMAoGA1UEBwwDVEtLMQswCQYDVQQKDAJNVzEM MAoGA1UECwwDb3BzMRwwGgYD [snip] Any help would be welcome. -- William Leese Production Engineer, Operations, Asia Pacific Meltwater Group m: +81 80 4946 0329 skype: william.leese1 w: meltwater.com This email and any attachment(s) is intended for and confidential to the addressee. If you are neither the addressee nor an authorized recipient for the addressee, please notify us of receipt, delete this message from your system and do not use, copy or disseminate the information in, or attached to it, in any way. Our messages are checked for viruses but please note that we do not accept liability for any viruses which may be transmitted in or with this message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fosterb at edgeandvertex.org Wed Nov 6 07:33:46 2013 From: fosterb at edgeandvertex.org (Brett Foster) Date: Tue, 5 Nov 2013 23:33:46 -0800 Subject: [Freeipa-users] reverse DNS and replicas Message-ID: Alright -- I'm stumped. What is the motivation for requiring reverse lookups for replicas? Is there a way to turn the check off? Others ideas? Here's what I got: I set up freeipa server and client. The systems are connected over OpenVPN to create a private network between clients and server (10.5.x.x). Traffic to 10.5.0.x subset is routed over VPN; otherwise traffic uses the local network connection (including DNS servers provided over DHCP). For better or worse, I found myself exposing the internal addresses via the public interface of the FreeIPA server. This, however, makes it impossible to do the reverse lookup of internal servers. Clients and freeipa server appear to be happy with this arrangement. Replica not so much. FreeIPA Server: 10.5.0.1 FreeIPA Replica: 10.5.0.2 Client 1: 10.5.0.3 Client 2: 10.5.0.4 and so on... Error: 2013-11-06T06:53:41Z DEBUG Check reverse address of 10.5.0.1 2013-11-06T06:53:46Z DEBUG Check failed: [Errno 1] Unknown host 2013-11-06T06:53:46Z DEBUG The ipa-replica-install command failed, exception: HostReverseLookupError: Unable to resolve the reverse ip address, check /etc/hosts or DNS name resolution Brett -------------- next part -------------- An HTML attachment was scrubbed... URL: From fosterb at edgeandvertex.org Wed Nov 6 07:38:48 2013 From: fosterb at edgeandvertex.org (Brett Foster) Date: Tue, 5 Nov 2013 23:38:48 -0800 Subject: [Freeipa-users] reverse DNS and replicas In-Reply-To: References: Message-ID: Of course, as soon as I send this I notice the --no-host-dns. Figures. On Tue, Nov 5, 2013 at 11:33 PM, Brett Foster wrote: > Alright -- I'm stumped. What is the motivation for requiring reverse > lookups for replicas? Is there a way to turn the check off? Others ideas? > > Here's what I got: > > I set up freeipa server and client. The systems are connected over OpenVPN > to create a private network between clients and server (10.5.x.x). Traffic > to 10.5.0.x subset is routed over VPN; otherwise traffic uses the local > network connection (including DNS servers provided over DHCP). > > For better or worse, I found myself exposing the internal addresses via > the public interface of the FreeIPA server. This, however, makes it > impossible to do the reverse lookup of internal servers. > > Clients and freeipa server appear to be happy with this arrangement. > Replica not so much. > > FreeIPA Server: 10.5.0.1 > FreeIPA Replica: 10.5.0.2 > Client 1: 10.5.0.3 > Client 2: 10.5.0.4 > and so on... > > Error: > 2013-11-06T06:53:41Z DEBUG Check reverse address of 10.5.0.1 > 2013-11-06T06:53:46Z DEBUG Check failed: [Errno 1] Unknown host > 2013-11-06T06:53:46Z DEBUG The ipa-replica-install command failed, > exception: HostReverseLookupError: Unable to resolve the reverse ip > address, check /etc/hosts or DNS name resolution > > Brett > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arthur at deus.pro Wed Nov 6 08:16:18 2013 From: arthur at deus.pro (Arthur Faizullin) Date: Wed, 06 Nov 2013 14:16:18 +0600 Subject: [Freeipa-users] question about generating certificates Message-ID: <1383725778.3819.15.camel@coruscant.bashnl.ru> Hi, everyone! I feel myself very uncomfortable asking this question, since usually I found documentation easy to understand&read. (Thanks for that!) But there is the point, that I could not understand. That point is generating certificates using IPA CA. I have read about this: https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/request-service-service.html https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/certmongerX.html https://git.fedorahosted.org/cgit/certmonger.git/tree/doc/getting-started.txt but I did not get the point! :( So, I have build test environment as shown in attached document, if you need details, you may look at it. for short I have 2 servers: 1. IPA-server: ipaserver.example.com 2. PostgreSQL-server: postgresql.example.com PostgreSQL was chosen as an example (nor bad, nor good) and I try to generate key&certificate: $ sudo ipa-getcert request -f /home/tuser/server.crt -k /home/tuser/server.key -K postgresql/postgresql.example.com -N CN=postgresql.example.com -D postgresql.example.com I get this answer: New signing request "20131106075356" added. But what to do with this answer? I can get list of requests, but that does not make it more clear: $ ipa-getcert list Error connecting to DBus. Please verify that the message bus (D-Bus) service is running. [tuser at postgresql ~]$ sudo ipa-getcert list Number of certificates and requests being tracked: 2. Request ID '20131101115647': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/pki/nssdb',nickname='IPA Machine Certificate - postgresql.example.com',token='NSS Certificate DB' certificate: type=NSSDB,location='/etc/pki/nssdb',nickname='IPA Machine Certificate - postgresql.example.com',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=EXAMPLE.COM subject: CN=postgresql.example.com,O=EXAMPLE.COM expires: 2015-11-02 11:56:48 UTC eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes Request ID '20131106075356': status: NEED_KEY_PAIR stuck: no key pair storage: type=FILE,location='/home/tuser/server.key' certificate: type=FILE,location='/home/tuser/server.crt' CA: IPA issuer: subject: expires: unknown pre-save command: post-save command: track: yes auto-renew: yes ______________________________ Best regards, Arthur Fayzullin -------------- next part -------------- A non-text attachment was scrubbed... Name: IPASSLCA.pdf Type: application/pdf Size: 147674 bytes Desc: not available URL: From arthur at deus.pro Wed Nov 6 12:01:02 2013 From: arthur at deus.pro (Arthur Faizullin) Date: Wed, 06 Nov 2013 18:01:02 +0600 Subject: [Freeipa-users] question about generating certificates In-Reply-To: <1383725778.3819.15.camel@coruscant.bashnl.ru> References: <1383725778.3819.15.camel@coruscant.bashnl.ru> Message-ID: <1383739262.3819.41.camel@coruscant.bashnl.ru> ????? ??????? ??????????? has give me advise that the problem may be in Selinux. so I has stoped tracking previous request by $ sudo ipa-getcert stop-tracking -i 20131106075356 and has generated new request # ipa-getcert request -f /var/lib/certmonger/requests/server.crt -k /var/lib/certmonger/requests/server.key -K postgresql/postgresql.example.com -N CN=postgresql.example.com -D postgresql.example.com that made desired files to appear at /var/lib/certmonger/requests/ that is okay! :) but! I want them in /var/lib/pgsql/9.3/data/ so what is the problem? why not just copy them at that directory? the problem is that when I list cert requests, I see this: Request ID '20131106113520': status: MONITORING stuck: no key pair storage: type=FILE,location='/var/lib/certmonger/requests/server.key' certificate: type=FILE,location='/var/lib/certmonger/requests/server.crt' CA: IPA issuer: CN=Certificate Authority,O=EXAMPLE.COM subject: CN=postgresql.example.com,O=EXAMPLE.COM expires: 2015-11-07 11:35:20 UTC eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes we can see that file location in that list is defined at request time. Shall I make Selinux to let certmonger to access /var/lib/pgsql ? or is there any other solution? And I think that there mast be note at documentation about such situations with Selinux. ? ??, 06/11/2013 ? 14:16 +0600, Arthur Faizullin ?????: > Hi, everyone! > I feel myself very uncomfortable asking this question, since usually I > found documentation easy to understand&read. (Thanks for that!) > But there is the point, that I could not understand. > That point is generating certificates using IPA CA. > I have read about this: > https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/request-service-service.html > https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/certmongerX.html > https://git.fedorahosted.org/cgit/certmonger.git/tree/doc/getting-started.txt > but I did not get the point! :( > So, I have build test environment as shown in attached document, if you > need details, you may look at it. > for short I have 2 servers: > 1. IPA-server: ipaserver.example.com > 2. PostgreSQL-server: postgresql.example.com > PostgreSQL was chosen as an example (nor bad, nor good) > and I try to generate key&certificate: > > $ sudo ipa-getcert request -f /home/tuser/server.crt > -k /home/tuser/server.key -K postgresql/postgresql.example.com -N > CN=postgresql.example.com -D postgresql.example.com > > I get this answer: > > New signing request "20131106075356" added. > > But what to do with this answer? I can get list of requests, but that > does not make it more clear: > > $ ipa-getcert list > Error connecting to DBus. > Please verify that the message bus (D-Bus) service is running. > [tuser at postgresql ~]$ sudo ipa-getcert list > Number of certificates and requests being tracked: 2. > Request ID '20131101115647': > status: MONITORING > stuck: no > key pair storage: type=NSSDB,location='/etc/pki/nssdb',nickname='IPA > Machine Certificate - postgresql.example.com',token='NSS Certificate DB' > certificate: type=NSSDB,location='/etc/pki/nssdb',nickname='IPA Machine > Certificate - postgresql.example.com',token='NSS Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=EXAMPLE.COM > subject: CN=postgresql.example.com,O=EXAMPLE.COM > expires: 2015-11-02 11:56:48 UTC > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: > post-save command: > track: yes > auto-renew: yes > Request ID '20131106075356': > status: NEED_KEY_PAIR > stuck: no > key pair storage: type=FILE,location='/home/tuser/server.key' > certificate: type=FILE,location='/home/tuser/server.crt' > CA: IPA > issuer: > subject: > expires: unknown > pre-save command: > post-save command: > track: yes > auto-renew: yes > > ______________________________ > Best regards, Arthur Fayzullin > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From dpal at redhat.com Wed Nov 6 12:20:55 2013 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 06 Nov 2013 07:20:55 -0500 Subject: [Freeipa-users] Requesting contact with users running PassSync AD -> FreeIPA In-Reply-To: <4929A617-9538-45E8-8C44-B57A26438ED7@melt.se> References: <52790948.3080206@melt.se> <52790B6E.7060608@redhat.com> <1D629EDD-8065-4429-AFA2-D2A72D2F9489@melt.se> <527922D6.1010502@redhat.com> <4929A617-9538-45E8-8C44-B57A26438ED7@melt.se> Message-ID: <527A3427.8040207@redhat.com> On 11/05/2013 02:05 PM, EP wrote: > Thanks for your answers so far. > > A question about cross realm trusts though: This requires the AD servers to be available when doing a login via FreeIPA, right? Or is FreeIPA caching information from AD? > > We don't want Linux logins to be dependent on a windows server being available, that won't end well :) Yes it is because the authentication actually happens against the domain the user belongs to. If user is in AD then AD will authenticate the user and then the tickets will be exchanged between domains to allow user to access services in other domains. If you want users to be in IPA then you would have to sync. > > _______________________________________________ > 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 dpal at redhat.com Wed Nov 6 12:25:06 2013 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 06 Nov 2013 07:25:06 -0500 Subject: [Freeipa-users] Revisiting ILO In-Reply-To: References: Message-ID: <527A3522.4010902@redhat.com> On 11/05/2013 02:51 PM, KodaK wrote: > If I use the whole connection string: > > uid=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com > > I can authenticate. Does this count as SOLVED? If so can you please reply with the SOLVED in the subject? > > > On Tue, Nov 5, 2013 at 1:40 PM, KodaK > wrote: > > I'm attempting to get HP ILO authenticating against IPA again. > > I've configured the user context in ILO as: > > cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com > > When ILO tries to connect, it sends the string: > > CN=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com > > Which, of course, doesn't exist. IPA uses uid=, but as > far as I can tell I can't tell ILO to use a different username > attribute. It doesn't even look like it's trying to use a > username attribute. > > I've tried to force it to look for uid=jebalicki by using > "uid=jebalicki" in the login field, but that fails too. The > errors in the errors log look like this: > > > [05/Nov/2013:13:22:05 -0600] ipalockout_preop - [file > ipa_lockout.c, line 645]: Failed to retrieve entry "jebalicki": 32 > [05/Nov/2013:13:22:05 -0600] ipalockout_postop - [file > ipa_lockout.c, line 421]: Failed to retrieve entry "jebalicki": 32 > [05/Nov/2013:13:22:05 -0600] ipalockout_preop - [file > ipa_lockout.c, line 645]: Failed to retrieve entry > "CN=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com": > 32 > [05/Nov/2013:13:22:05 -0600] ipalockout_postop - [file > ipa_lockout.c, line 421]: Failed to retrieve entry > "CN=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com": > 32 > [05/Nov/2013:13:22:05 -0600] ipalockout_preop - [file > ipa_lockout.c, line 645]: Failed to retrieve entry "jebalicki": 32 > [05/Nov/2013:13:22:05 -0600] ipalockout_postop - [file > ipa_lockout.c, line 421]: Failed to retrieve entry "jebalicki": 32 > [05/Nov/2013:13:22:05 -0600] ipalockout_preop - [file > ipa_lockout.c, line 645]: Failed to retrieve entry > "CN=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com": > 32 > [05/Nov/2013:13:22:05 -0600] ipalockout_postop - [file > ipa_lockout.c, line 421]: Failed to retrieve entry > "CN=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com": > 32 > [05/Nov/2013:13:22:05 -0600] ipalockout_preop - [file > ipa_lockout.c, line 645]: Failed to retrieve entry "jebalicki": 32 > [05/Nov/2013:13:22:05 -0600] ipalockout_postop - [file > ipa_lockout.c, line 421]: Failed to retrieve entry "jebalicki": 32 > [05/Nov/2013:13:22:05 -0600] ipalockout_preop - [file > ipa_lockout.c, line 645]: Failed to retrieve entry > "CN=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com": > 32 > [05/Nov/2013:13:22:05 -0600] ipalockout_postop - [file > ipa_lockout.c, line 421]: Failed to retrieve entry > "CN=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com": > 32 > [05/Nov/2013:13:27:39 -0600] ipalockout_preop - [file > ipa_lockout.c, line 645]: Failed to retrieve entry "uid=jebalicki": 32 > [05/Nov/2013:13:27:39 -0600] ipalockout_postop - [file > ipa_lockout.c, line 421]: Failed to retrieve entry "uid=jebalicki": 32 > [05/Nov/2013:13:27:39 -0600] ipalockout_preop - [file > ipa_lockout.c, line 645]: Failed to retrieve entry > "CN=uid=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com": > 32 > [05/Nov/2013:13:27:39 -0600] ipalockout_postop - [file > ipa_lockout.c, line 421]: Failed to retrieve entry > "CN=uid=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com": > 32 > [05/Nov/2013:13:27:39 -0600] ipalockout_preop - [file > ipa_lockout.c, line 645]: Failed to retrieve entry "uid=jebalicki": 32 > [05/Nov/2013:13:27:39 -0600] ipalockout_postop - [file > ipa_lockout.c, line 421]: Failed to retrieve entry "uid=jebalicki": 32 > [05/Nov/2013:13:27:39 -0600] ipalockout_preop - [file > ipa_lockout.c, line 645]: Failed to retrieve entry > "CN=uid=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com": > 32 > [05/Nov/2013:13:27:39 -0600] ipalockout_postop - [file > ipa_lockout.c, line 421]: Failed to retrieve entry > "CN=uid=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com": > 32 > [05/Nov/2013:13:27:39 -0600] ipalockout_preop - [file > ipa_lockout.c, line 645]: Failed to retrieve entry "uid=jebalicki": 32 > [05/Nov/2013:13:27:39 -0600] ipalockout_postop - [file > ipa_lockout.c, line 421]: Failed to retrieve entry "uid=jebalicki": 32 > [05/Nov/2013:13:27:39 -0600] ipalockout_preop - [file > ipa_lockout.c, line 645]: Failed to retrieve entry > "CN=uid=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com": > 32 > [05/Nov/2013:13:27:39 -0600] ipalockout_postop - [file > ipa_lockout.c, line 421]: Failed to retrieve entry > "CN=uid=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com": > 32 > > And the access log looks like this: > > [05/Nov/2013:13:32:06 -0600] conn=214941 fd=438 slot=438 SSL > connection from 10.200.10.192 to 10.200.16.170 > [05/Nov/2013:13:32:06 -0600] conn=214941 SSL 256-bit AES > [05/Nov/2013:13:32:06 -0600] conn=214941 op=0 BIND > dn="uid=jebalicki" method=128 version=2 > [05/Nov/2013:13:32:06 -0600] conn=214941 op=0 RESULT err=32 tag=97 > nentries=0 etime=0 > [05/Nov/2013:13:32:06 -0600] conn=214941 op=1 BIND > dn="CN=uid=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com" > method=128 version=2 > [05/Nov/2013:13:32:07 -0600] conn=214941 op=1 RESULT err=32 tag=97 > nentries=0 etime=1 > [05/Nov/2013:13:32:07 -0600] conn=214941 op=2 UNBIND > [05/Nov/2013:13:32:07 -0600] conn=214941 op=2 fd=438 closed - U1 > [05/Nov/2013:13:32:07 -0600] conn=214942 fd=439 slot=439 SSL > connection from 10.200.10.192 to 10.200.16.170 > [05/Nov/2013:13:32:07 -0600] conn=214942 SSL 256-bit AES > [05/Nov/2013:13:32:07 -0600] conn=214942 op=0 BIND > dn="uid=jebalicki" method=128 version=2 > [05/Nov/2013:13:32:07 -0600] conn=214942 op=0 RESULT err=32 tag=97 > nentries=0 etime=0 > [05/Nov/2013:13:32:07 -0600] conn=214942 op=1 UNBIND > [05/Nov/2013:13:32:07 -0600] conn=214942 op=1 fd=439 closed - U1 > [05/Nov/2013:13:32:07 -0600] conn=214943 fd=438 slot=438 SSL > connection from 10.200.10.192 to 10.200.16.170 > [05/Nov/2013:13:32:07 -0600] conn=214943 SSL 256-bit AES > [05/Nov/2013:13:32:07 -0600] conn=214943 op=0 BIND > dn="CN=uid=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com" > method=128 version=2 > [05/Nov/2013:13:32:07 -0600] conn=214943 op=0 RESULT err=32 tag=97 > nentries=0 etime=0 > [05/Nov/2013:13:32:07 -0600] conn=214943 op=1 UNBIND > [05/Nov/2013:13:32:07 -0600] conn=214943 op=1 fd=438 closed - U1 > > Is there any way to force things on the IPA side? Can I > automatically attach on the necessary components to the provided > username? > > > > > -- > The government is going to read our mail anyway, might as well make it > tough for them. GPG Public key ID: B6A1A7C6 > > > _______________________________________________ > 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 Nov 6 12:38:00 2013 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 06 Nov 2013 07:38:00 -0500 Subject: [Freeipa-users] New login procedure for FreeIPA wiki - need advice! Message-ID: <527A3828.9080300@redhat.com> Hello, We are trying to make access to the FreeIPA wiki easier and allow contributions without addition overhead. In the past to make any change to wiki one had to have a special wiki account. The procedure of creating such account was cumbersome. We added support for OpenID. Among available providers we selected to support Fedora accounting system at least for now. OpenID configuration allows other providers like Google or Yahoo but we were concerned that trusting them might allow spam bots to connect and pollute the wiki. May be we are over cautious and we should open up to those providers? We are seeking advice from you on what is better. Right now it does not allow logins with old accounts any more, only with OpenID. Unfortunately it is all of nothing. But we do not want people that had accounts and were able to contribute in the past but do not have Fedora account to loose ability to contribute. Any ideas and suggestions welcome! -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From abokovoy at redhat.com Wed Nov 6 12:52:01 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 6 Nov 2013 14:52:01 +0200 Subject: [Freeipa-users] question about generating certificates In-Reply-To: <1383739262.3819.41.camel@coruscant.bashnl.ru> References: <1383725778.3819.15.camel@coruscant.bashnl.ru> <1383739262.3819.41.camel@coruscant.bashnl.ru> Message-ID: <20131106125201.GI25335@redhat.com> On Wed, 06 Nov 2013, Arthur Faizullin wrote: >????? ??????? ??????????? has give me advise that the >problem may be in Selinux. >so I has stoped tracking previous request by >$ sudo ipa-getcert stop-tracking -i 20131106075356 > >and has generated new request ># ipa-getcert request -f /var/lib/certmonger/requests/server.crt >-k /var/lib/certmonger/requests/server.key -K >postgresql/postgresql.example.com -N CN=postgresql.example.com -D >postgresql.example.com > >that made desired files to appear at /var/lib/certmonger/requests/ >that is okay! :) >but! I want them in /var/lib/pgsql/9.3/data/ >so what is the problem? why not just copy them at that directory? >the problem is that when I list cert requests, I see this: >Request ID '20131106113520': > status: MONITORING > stuck: no > key pair storage: >type=FILE,location='/var/lib/certmonger/requests/server.key' > certificate: >type=FILE,location='/var/lib/certmonger/requests/server.crt' > CA: IPA > issuer: CN=Certificate Authority,O=EXAMPLE.COM > subject: CN=postgresql.example.com,O=EXAMPLE.COM > expires: 2015-11-07 11:35:20 UTC > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: > post-save command: > track: yes > auto-renew: yes > >we can see that file location in that list is defined at request time. > >Shall I make Selinux to let certmonger to access /var/lib/pgsql ? or is >there any other solution? certmonger does run under certmonger_t SELinux type and system_r role. It can already write to file contexts named certmonger_*_t and cert_t. For storing certificates you would need to use cert_t file context. mkdir -p /var/lib/pgsql/9.3/data/certs semanage fcontext -a -t cert_t '/var/lib/pgsql/9.3/data/certs(/.*)?' restorecon -R -v /var/lib/pgsql/9.3/data/certs I would advise you against placing the files directly in /var/lib/pgsql/9.3/data as opposed to the subdirectory. It is safer to specify path to the certificate in pgsql configuration. >And I think that there mast be note at documentation about such >situations with Selinux. Yes. You can also install selinux-policy-devel package and read certmonger_selinux (8) manpage. Can you open a ticket against FreeIPA documentation. -- / Alexander Bokovoy From dpal at redhat.com Wed Nov 6 12:55:45 2013 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 06 Nov 2013 07:55:45 -0500 Subject: [Freeipa-users] question about generating certificates In-Reply-To: <1383739262.3819.41.camel@coruscant.bashnl.ru> References: <1383725778.3819.15.camel@coruscant.bashnl.ru> <1383739262.3819.41.camel@coruscant.bashnl.ru> Message-ID: <527A3C51.6050100@redhat.com> On 11/06/2013 07:01 AM, Arthur Faizullin wrote: > ????? ??????? ??????????? has give me advise that the > problem may be in Selinux. > so I has stoped tracking previous request by > $ sudo ipa-getcert stop-tracking -i 20131106075356 > > and has generated new request > # ipa-getcert request -f /var/lib/certmonger/requests/server.crt > -k /var/lib/certmonger/requests/server.key -K > postgresql/postgresql.example.com -N CN=postgresql.example.com -D > postgresql.example.com > > that made desired files to appear at /var/lib/certmonger/requests/ > that is okay! :) > but! I want them in /var/lib/pgsql/9.3/data/ > so what is the problem? why not just copy them at that directory? > the problem is that when I list cert requests, I see this: > Request ID '20131106113520': > status: MONITORING > stuck: no > key pair storage: > type=FILE,location='/var/lib/certmonger/requests/server.key' > certificate: > type=FILE,location='/var/lib/certmonger/requests/server.crt' > CA: IPA > issuer: CN=Certificate Authority,O=EXAMPLE.COM > subject: CN=postgresql.example.com,O=EXAMPLE.COM > expires: 2015-11-07 11:35:20 UTC > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: > post-save command: > track: yes > auto-renew: yes > > we can see that file location in that list is defined at request time. > > Shall I make Selinux to let certmonger to access /var/lib/pgsql ? or is > there any other solution? I think yes. And I recall this is not the first time this comes up. My memory might be failing me but I vaguely remember that we discussed this. However I could not find any bug or ticket on the matter so I created this https://bugzilla.redhat.com/show_bug.cgi?id=1027265 > > And I think that there mast be note at documentation about such > situations with Selinux. > > ? ??, 06/11/2013 ? 14:16 +0600, Arthur Faizullin ?????: >> Hi, everyone! >> I feel myself very uncomfortable asking this question, since usually I >> found documentation easy to understand&read. (Thanks for that!) >> But there is the point, that I could not understand. >> That point is generating certificates using IPA CA. >> I have read about this: >> https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/request-service-service.html >> https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/certmongerX.html >> https://git.fedorahosted.org/cgit/certmonger.git/tree/doc/getting-started.txt >> but I did not get the point! :( >> So, I have build test environment as shown in attached document, if you >> need details, you may look at it. >> for short I have 2 servers: >> 1. IPA-server: ipaserver.example.com >> 2. PostgreSQL-server: postgresql.example.com >> PostgreSQL was chosen as an example (nor bad, nor good) >> and I try to generate key&certificate: >> >> $ sudo ipa-getcert request -f /home/tuser/server.crt >> -k /home/tuser/server.key -K postgresql/postgresql.example.com -N >> CN=postgresql.example.com -D postgresql.example.com >> >> I get this answer: >> >> New signing request "20131106075356" added. >> >> But what to do with this answer? I can get list of requests, but that >> does not make it more clear: >> >> $ ipa-getcert list >> Error connecting to DBus. >> Please verify that the message bus (D-Bus) service is running. >> [tuser at postgresql ~]$ sudo ipa-getcert list >> Number of certificates and requests being tracked: 2. >> Request ID '20131101115647': >> status: MONITORING >> stuck: no >> key pair storage: type=NSSDB,location='/etc/pki/nssdb',nickname='IPA >> Machine Certificate - postgresql.example.com',token='NSS Certificate DB' >> certificate: type=NSSDB,location='/etc/pki/nssdb',nickname='IPA Machine >> Certificate - postgresql.example.com',token='NSS Certificate DB' >> CA: IPA >> issuer: CN=Certificate Authority,O=EXAMPLE.COM >> subject: CN=postgresql.example.com,O=EXAMPLE.COM >> expires: 2015-11-02 11:56:48 UTC >> eku: id-kp-serverAuth,id-kp-clientAuth >> pre-save command: >> post-save command: >> track: yes >> auto-renew: yes >> Request ID '20131106075356': >> status: NEED_KEY_PAIR >> stuck: no >> key pair storage: type=FILE,location='/home/tuser/server.key' >> certificate: type=FILE,location='/home/tuser/server.crt' >> CA: IPA >> issuer: >> subject: >> expires: unknown >> pre-save command: >> post-save command: >> track: yes >> auto-renew: yes >> >> ______________________________ >> Best regards, Arthur Fayzullin >> _______________________________________________ >> 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 dpal at redhat.com Wed Nov 6 13:05:44 2013 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 06 Nov 2013 08:05:44 -0500 Subject: [Freeipa-users] ui login error and questions about replication In-Reply-To: <5279B4A8.3020802@redhat.com> References: <5278E564.6030403@martos.bme.hu> <20131105130425.GE25335@redhat.com> <5278FE13.6030401@redhat.com> <527983E2.8000708@martos.bme.hu> <5279B4A8.3020802@redhat.com> Message-ID: <527A3EA8.1050001@redhat.com> On 11/05/2013 10:16 PM, Rob Crittenden wrote: >> >>>> If you have deployed original IPA server with integrated CA, then your >>>> other replicas better to have at least one with CA configured to allow >>>> proper recovery in case primary one is destroyed. >> >> Is there any caveats to not deploy CA on all replicas as a simples >> solution? > > You don't need a CA on every single replica, but you probably want at > least two. > It is important to understand that CA is crucial to IPA so if for some reason you loose all the replicas that have CA you are facing a redeployment. This is why we suggest having "enough" replicas with CA and also to do periodically snapshot one of the replicas with CA so that everything is lost you can recover from the snapshot. We are working on a more comprehensive disaster recovery document but it is worth mentioning it here. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From tompos at martos.bme.hu Wed Nov 6 13:18:07 2013 From: tompos at martos.bme.hu (Tamas Papp) Date: Wed, 06 Nov 2013 14:18:07 +0100 Subject: [Freeipa-users] ui login error and questions about replication In-Reply-To: <52799696.80308@redhat.com> References: <5278E564.6030403@martos.bme.hu> <20131105130425.GE25335@redhat.com> <5278FE13.6030401@redhat.com> <52790676.9080105@martos.bme.hu> <527907A6.9040809@redhat.com> <52794F09.1060904@martos.bme.hu> <52795436.7040406@redhat.com> <52797DF5.6050701@martos.bme.hu> <52799696.80308@redhat.com> Message-ID: <527A418F.3020704@martos.bme.hu> On 11/06/2013 02:08 AM, Rich Megginson wrote: > On 11/05/2013 04:23 PM, Tamas Papp wrote: >> On 11/05/2013 09:25 PM, Rich Megginson wrote: >>> On 11/05/2013 01:03 PM, Tamas Papp wrote: >>>> On 11/05/2013 03:58 PM, Rich Megginson wrote: >>>>> On 11/05/2013 07:53 AM, Tamas Papp wrote: >>>>>> On 11/05/2013 03:17 PM, Rich Megginson wrote: >>>>>>> https://fedorahosted.org/389/ticket/47516 >>>>>>> >>>>>>> This has been fixed upstream and in some releases - to allow >>>>>>> replication to proceed despite excessive clock skew - what is your >>>>>>> 389-ds-base version and platform? >>>>>> What is the clock skewed? The date and time is the same on both >>>>>> machines. >>>>> VMs are notorious for having the clocks get out of sync - even >>>>> temporarily. >>>> What do you mean by this? >>>> I definitely see the same time on the machines. >>>> Also I can see in the log, that the replication is resumed. There >>>> is no >>>> messages about the broken replication after the resume message. >>>> >>>>>> freeipa-admintools-3.3.2-1.fc19.x86_64 >>>>>> freeipa-client-3.3.2-1.fc19.x86_64 >>>>>> freeipa-python-3.3.2-1.fc19.x86_64 >>>>>> freeipa-server-3.3.2-1.fc19.x86_64 >>>>>> libipa_hbac-1.11.1-4.fc19.x86_64 >>>>>> libipa_hbac-python-1.11.1-4.fc19.x86_64 >>>>>> sssd-ipa-1.11.1-4.fc19.x86_64 >>>>>> 389-ds-base-libs-1.3.1.12-1.fc19.x86_64 >>>>>> 389-ds-base-1.3.1.12-1.fc19.x86_64 >>>>>> >>>>>> Linux ipa31.bph.cxn 3.11.6-201.fc19.x86_64 #1 SMP Sat Nov 2 >>>>>> 14:09:09 UTC >>>>>> 2013 x86_64 x86_64 x86_64 GNU/Linux >>>>>> Fedora 19. >>>>>> >>>>>> >>>>>> How can I fix it? >>>>> ldapmodify -x -D "cn=directory manager" -W <>>>> dn: cn=config >>>>> changetype: modify >>>>> replace: nsslapd-ignore-time-skew >>>>> nsslapd-ignore-time-skew: on >>>>> EOF >>>>> >>>>> Do this on all of your servers. >>>> I tried this, but no joy. Still not good:/ >>> Can you describe the exact steps you took, on all replicas? >> I created ldif files: >> >> # cat replication_ignore-time-skew.ldif >> dn: cn=config >> changetype: modify >> replace: nsslapd-ignore-time-skew >> nsslapd-ignore-time-skew: on >> >> Then: >> >> $ ldapmodify -x -D "cn=directory manager" -W -f >> replication_ignore-time-skew.ldif >> >> >> >> But I don't see the changes: >> >> # ldapsearch -x|grep -i ignore > ldapsearch -x -D "cn=directory manager" -W -s base -b cn=config > 'objectclass=*' nsslapd-ignore-time-skew You're right, I tried it with wrong base dn. Thanks, tamas From tompos at martos.bme.hu Wed Nov 6 13:20:45 2013 From: tompos at martos.bme.hu (Tamas Papp) Date: Wed, 06 Nov 2013 14:20:45 +0100 Subject: [Freeipa-users] ui login error and questions about replication In-Reply-To: <52799657.9070406@redhat.com> References: <5278E564.6030403@martos.bme.hu> <20131105130425.GE25335@redhat.com> <5278FE13.6030401@redhat.com> <52790676.9080105@martos.bme.hu> <527907A6.9040809@redhat.com> <5279808F.5030609@martos.bme.hu> <52799657.9070406@redhat.com> Message-ID: <527A422D.6040105@martos.bme.hu> On 11/06/2013 02:07 AM, Rich Megginson wrote: > On 11/05/2013 04:34 PM, Tamas Papp wrote: >> On 11/05/2013 03:58 PM, Rich Megginson wrote: >>> On 11/05/2013 07:53 AM, Tamas Papp wrote: >>>> On 11/05/2013 03:17 PM, Rich Megginson wrote: >>>>> https://fedorahosted.org/389/ticket/47516 >>>>> >>>>> This has been fixed upstream and in some releases - to allow >>>>> replication to proceed despite excessive clock skew - what is your >>>>> 389-ds-base version and platform? >>>> What is the clock skewed? The date and time is the same on both >>>> machines. >>> VMs are notorious for having the clocks get out of sync - even >>> temporarily. >> Eventually you were right, it looks, that the problem is related to the >> virtualization, thanks for the tip. >> >> Although I wouldn't say, it's because of messy VMs. It definitely must >> be a software bug or misconfiguration, otherwise a VM should always >> looks the same as a bare metal machine. >> >> Actually in my specific case I don't see the reason, why it is working >> with and not with if >> the time in the VM synchronized after bootup. > You can file a ticket. I'm not absolutely sure, that this was the root cause of the problem. tamas From indira at indolinux.com Wed Nov 6 05:15:58 2013 From: indira at indolinux.com (indira) Date: Wed, 6 Nov 2013 05:15:58 +0000 (UTC) Subject: [Freeipa-users] rhel 5 client in a rhel 6 domain? References: <1374510726.4906.6.camel@localhost.localdomain> <51ED6ECB.40208@redhat.com> <1374515508.4906.8.camel@localhost.localdomain> <1374524920.4906.11.camel@localhost.localdomain> <51EDA8E2.4090702@redhat.com> <1374585781.8235.1.camel@localhost.localdomain> <1374599628.8235.8.camel@localhost.localdomain> <1374603722.8235.11.camel@localhost.localdomain> <51EFD88D.9040304@redhat.com> <1374674942.7479.1.camel@localhost.localdomain> Message-ID: Armstrong, Kenneth Lawrence writes: hi.. has the problem fixed??? From tompos at martos.bme.hu Wed Nov 6 13:41:29 2013 From: tompos at martos.bme.hu (Tamas Papp) Date: Wed, 06 Nov 2013 14:41:29 +0100 Subject: [Freeipa-users] ui login error and questions about replication In-Reply-To: <5279B4A8.3020802@redhat.com> References: <5278E564.6030403@martos.bme.hu> <20131105130425.GE25335@redhat.com> <5278FE13.6030401@redhat.com> <527983E2.8000708@martos.bme.hu> <5279B4A8.3020802@redhat.com> Message-ID: <527A4709.7040200@martos.bme.hu> On 11/06/2013 04:16 AM, Rob Crittenden wrote: > >> >>>> >>>>> 5. If I have a network like this: >>>>> >>>>> A1______B1 >>>>> A2 B2 >>>>> >>>>> A2 and B1,2 are replicated from A1 >>>>> >>>>> If the connection gets lost between A and B site, are B1 and 2 (and >>>>> A1,2) replicated fine? >>>> I assume from the above that B1 does not know about B2 (and vice >>>> versa)? >> >> Well, that is actually one of the questions. B1 and B2 are on the same >> sites and failover nodes from point of view of clients. > > You can manage the replication topology with ipa-replica-manage > connect and disconnect. So if you want B1 and B2 connected you can do > that. > >> >>>> Once connectivity between sites A and B restored, all unreplicated >>>> data >>>> will be replicated. There could be conflicts if there were changes on >>>> both sides during the split but majority of them are solved >>>> automatically by 389-ds. >> >> The main question is that B1 and B2 are not replicated to each other >> automatically? What about the case if >> >> A1 -- replication -- A2 --- replication --- B1 -- replication -- B2 >> >> If B1 gets destroyed, how B2 and A2 (and A1) gets synchronized? >> Especially automatically...? >> Is there such a failover configuration? > > No, the masters only replicate to the ones you tell them to, so if B1 > went away forever then B2 would never get any other updates unless you > explicitly made a connection to A1 or A2. Can the replication agreement be circular? *A2*-A1-B1-B2-*A**2*? Thanks, tamas -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Wed Nov 6 13:44:00 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 06 Nov 2013 08:44:00 -0500 Subject: [Freeipa-users] question about generating certificates In-Reply-To: <527A3C51.6050100@redhat.com> References: <1383725778.3819.15.camel@coruscant.bashnl.ru> <1383739262.3819.41.camel@coruscant.bashnl.ru> <527A3C51.6050100@redhat.com> Message-ID: <527A47A0.7050706@redhat.com> Dmitri Pal wrote: > On 11/06/2013 07:01 AM, Arthur Faizullin wrote: >> ????? ??????? ??????????? has give me advise that the >> problem may be in Selinux. >> so I has stoped tracking previous request by >> $ sudo ipa-getcert stop-tracking -i 20131106075356 >> >> and has generated new request >> # ipa-getcert request -f /var/lib/certmonger/requests/server.crt >> -k /var/lib/certmonger/requests/server.key -K >> postgresql/postgresql.example.com -N CN=postgresql.example.com -D >> postgresql.example.com >> >> that made desired files to appear at /var/lib/certmonger/requests/ >> that is okay! :) >> but! I want them in /var/lib/pgsql/9.3/data/ >> so what is the problem? why not just copy them at that directory? >> the problem is that when I list cert requests, I see this: >> Request ID '20131106113520': >> status: MONITORING >> stuck: no >> key pair storage: >> type=FILE,location='/var/lib/certmonger/requests/server.key' >> certificate: >> type=FILE,location='/var/lib/certmonger/requests/server.crt' >> CA: IPA >> issuer: CN=Certificate Authority,O=EXAMPLE.COM >> subject: CN=postgresql.example.com,O=EXAMPLE.COM >> expires: 2015-11-07 11:35:20 UTC >> eku: id-kp-serverAuth,id-kp-clientAuth >> pre-save command: >> post-save command: >> track: yes >> auto-renew: yes >> >> we can see that file location in that list is defined at request time. >> >> Shall I make Selinux to let certmonger to access /var/lib/pgsql ? or is >> there any other solution? > > I think yes. And I recall this is not the first time this comes up. > My memory might be failing me but I vaguely remember that we discussed this. > However I could not find any bug or ticket on the matter so I created this > https://bugzilla.redhat.com/show_bug.cgi?id=1027265 Typically in Fedora and RHEL certs are expected to go into /etc/pki/tls/certs and keys into /etc/pki/tls/private. These directories have the correct SELinux contexts. rob From pviktori at redhat.com Wed Nov 6 13:44:14 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 06 Nov 2013 14:44:14 +0100 Subject: [Freeipa-users] External CA In-Reply-To: References: Message-ID: <527A47AE.9070607@redhat.com> On 11/06/2013 06:32 AM, William Leese wrote: > Hi, > > Trying to install freeIPA and have it a sub-ca of an existing one. Sadly > I'm not getting anywhere. > > The version I have installed: > ipa-server-3.0.0-26.el6_4.4.x86_64 > > This is what I run: > > ipa-server-install -U -a testtest -p testtest > --external_cert_file=/root/server.pem > --external_ca_file=/root/cacert.pem -p testtest -P testtest -r > MELTWATER.COM > > Which runs this as part of the process: > > /usr/bin/pkisilent ConfigureCA -cs_hostname > vagrant-centos-6.meltwater.com > -cs_port 9445 -client_certdb_dir /tmp/tmp-bOrwSu -client_certdb_pwd > testtest -preop_pin 4hdia3IvPvf27Qo7kBbO -domain_name IPA -admin_user > admin -admin_email root at localhost -admin_password testtest -agent_name > ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa > -agent_cert_subject CN=ipa-ca-agent,O=MELTWATER.COM > -ldap_host vagrant-centos-6.meltwater.com > -ldap_port 7389 -bind_dn > cn="Directory Manager" -bind_password testtest -base_dn o=ipaca -db_name > ipaca -key_size 2048 -key_type rsa -key_algorithm SHA256withRSA > -save_p12 true -backup_pwd testtest -subsystem_name pki-cad -token_name > internal -ca_subsystem_cert_subject_name "CN=CA > Subsystem,O=MELTWATER.COM " > -ca_subsystem_cert_subject_name "CN=CA Subsystem,O=MELTWATER.COM > " -ca_ocsp_cert_subject_name "CN=OCSP > Subsystem,O=MELTWATER.COM " > -ca_server_cert_subject_name CN=vagrant-centos-6.meltwater.com > ,O=MELTWATER.COM > -ca_audit_signing_cert_subject_name "CN=CA > Audit,O=MELTWATER.COM " -ca_sign_cert_subject_name > "CN=Certificate Authority,O=MELTWATER.COM " > -external true -ext_ca_cert_file /root/server.pem > -ext_ca_cert_chain_file /root/cacert.pem > > All this results in this in the log: > Failed to create pkcs12 file. > [snip] > Error in BackupPanel(): updateStatus value is null > ERROR: ConfigureCA: BackupPanel() failure > ERROR: unable to create CA Can you attach the full error from the log? > Interestingly adding the option -save_p12 false to the pkisilent command > above results in: > > importCert string: importing with nickname: ipa-ca-agent > Already logged into to DB > ERROR:exception importing cert Security library failed to decode > certificate package: (-8183) security library: improperly formatted > DER-encoded message. > ERROR: AdminCertImportPanel() during cert import > ERROR: ConfigureCA: AdminCertImportPanel() failure > ERROR: unable to create CA > > While the option change seemed innocent, I honestly don't know if its > crucial to the install or not. Anyhow, things don't really progress anyway. > > I followed the documentation by signing the /root/ipa.csr with a test, > internal CA but somehow I can't get the install to proceed. > > [root at vagrant-centos-6 CA]# cat /root/server.pem > Certificate: > Data: > Version: 3 (0x2) > Serial Number: 2 (0x2) > Signature Algorithm: sha1WithRSAEncryption > Issuer: C=JP, ST=TK, L=TKK, O=MW, OU=ops, > CN=vagrant.localdomain/emailAddress=t at t.com > Validity > Not Before: Nov 6 05:12:09 2013 GMT > Not After : Nov 6 05:12:09 2014 GMT > Subject: O=MELTWATER.COM , CN=Certificate > Authority > [snip] > -----BEGIN CERTIFICATE----- > MIIDfDCCAmSgAwIBAgIBAjANBgkqhkiG9w0BAQUFADB5MQswCQYDVQQGEwJKUDEL > MAkGA1UECAwCVEsxDDAKBgNVBAcMA1RLSzELMAkGA1UECgwCTVcxDDAKBgNVBAsM > A29wczEcMBoGA1UEAwwTdmFncmFudC5sb2NhbGRvbWFpbjEWMBQGCSqGSIb3DQEJ > [snip] Try removing everything before the -----BEGIN CERTIFICATE----- line from the PEM. > [root at vagrant-centos-6 CA]# cat /root/cacert.pem > -----BEGIN CERTIFICATE----- > MIIDxTCCAq2gAwIBAgIJALIzKeNrwx2lMA0GCSqGSIb3DQEBBQUAMHkxCzAJBgNV > BAYTAkpQMQswCQYDVQQIDAJUSzEMMAoGA1UEBwwDVEtLMQswCQYDVQQKDAJNVzEM > MAoGA1UECwwDb3BzMRwwGgYD > [snip] > > Any help would be welcome. -- Petr? From rcritten at redhat.com Wed Nov 6 13:50:23 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 06 Nov 2013 08:50:23 -0500 Subject: [Freeipa-users] External CA In-Reply-To: References: Message-ID: <527A491F.4020801@redhat.com> William Leese wrote: > Hi, > > Trying to install freeIPA and have it a sub-ca of an existing one. Sadly > I'm not getting anywhere. > > The version I have installed: > ipa-server-3.0.0-26.el6_4.4.x86_64 > > This is what I run: > > ipa-server-install -U -a testtest -p testtest > --external_cert_file=/root/server.pem > --external_ca_file=/root/cacert.pem -p testtest -P testtest -r > MELTWATER.COM > > Which runs this as part of the process: > > /usr/bin/pkisilent ConfigureCA -cs_hostname > vagrant-centos-6.meltwater.com > -cs_port 9445 -client_certdb_dir /tmp/tmp-bOrwSu -client_certdb_pwd > testtest -preop_pin 4hdia3IvPvf27Qo7kBbO -domain_name IPA -admin_user > admin -admin_email root at localhost -admin_password testtest -agent_name > ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa > -agent_cert_subject CN=ipa-ca-agent,O=MELTWATER.COM > -ldap_host vagrant-centos-6.meltwater.com > -ldap_port 7389 -bind_dn > cn="Directory Manager" -bind_password testtest -base_dn o=ipaca -db_name > ipaca -key_size 2048 -key_type rsa -key_algorithm SHA256withRSA > -save_p12 true -backup_pwd testtest -subsystem_name pki-cad -token_name > internal -ca_subsystem_cert_subject_name "CN=CA > Subsystem,O=MELTWATER.COM " > -ca_subsystem_cert_subject_name "CN=CA Subsystem,O=MELTWATER.COM > " -ca_ocsp_cert_subject_name "CN=OCSP > Subsystem,O=MELTWATER.COM " > -ca_server_cert_subject_name CN=vagrant-centos-6.meltwater.com > ,O=MELTWATER.COM > -ca_audit_signing_cert_subject_name "CN=CA > Audit,O=MELTWATER.COM " -ca_sign_cert_subject_name > "CN=Certificate Authority,O=MELTWATER.COM " > -external true -ext_ca_cert_file /root/server.pem > -ext_ca_cert_chain_file /root/cacert.pem > > All this results in this in the log: > Failed to create pkcs12 file. > [snip] > Error in BackupPanel(): updateStatus value is null > ERROR: ConfigureCA: BackupPanel() failure > ERROR: unable to create CA > > Interestingly adding the option -save_p12 false to the pkisilent command > above results in: > > importCert string: importing with nickname: ipa-ca-agent > Already logged into to DB > ERROR:exception importing cert Security library failed to decode > certificate package: (-8183) security library: improperly formatted > DER-encoded message. > ERROR: AdminCertImportPanel() during cert import > ERROR: ConfigureCA: AdminCertImportPanel() failure > ERROR: unable to create CA > > While the option change seemed innocent, I honestly don't know if its > crucial to the install or not. Anyhow, things don't really progress anyway. > > I followed the documentation by signing the /root/ipa.csr with a test, > internal CA but somehow I can't get the install to proceed. > > [root at vagrant-centos-6 CA]# cat /root/server.pem > Certificate: > Data: > Version: 3 (0x2) > Serial Number: 2 (0x2) > Signature Algorithm: sha1WithRSAEncryption > Issuer: C=JP, ST=TK, L=TKK, O=MW, OU=ops, > CN=vagrant.localdomain/emailAddress=t at t.com > Validity > Not Before: Nov 6 05:12:09 2013 GMT > Not After : Nov 6 05:12:09 2014 GMT > Subject: O=MELTWATER.COM , CN=Certificate > Authority > [snip] > -----BEGIN CERTIFICATE----- > MIIDfDCCAmSgAwIBAgIBAjANBgkqhkiG9w0BAQUFADB5MQswCQYDVQQGEwJKUDEL > MAkGA1UECAwCVEsxDDAKBgNVBAcMA1RLSzELMAkGA1UECgwCTVcxDDAKBgNVBAsM > A29wczEcMBoGA1UEAwwTdmFncmFudC5sb2NhbGRvbWFpbjEWMBQGCSqGSIb3DQEJ > [snip] > > [root at vagrant-centos-6 CA]# cat /root/cacert.pem > -----BEGIN CERTIFICATE----- > MIIDxTCCAq2gAwIBAgIJALIzKeNrwx2lMA0GCSqGSIb3DQEBBQUAMHkxCzAJBgNV > BAYTAkpQMQswCQYDVQQIDAJUSzEMMAoGA1UEBwwDVEtLMQswCQYDVQQKDAJNVzEM > MAoGA1UECwwDb3BzMRwwGgYD > [snip] > > Any help would be welcome. I'd look in /var/log/pki-ca/debug for additional error information. rob From rmeggins at redhat.com Wed Nov 6 14:12:04 2013 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 06 Nov 2013 07:12:04 -0700 Subject: [Freeipa-users] ui login error and questions about replication In-Reply-To: <527A4709.7040200@martos.bme.hu> References: <5278E564.6030403@martos.bme.hu> <20131105130425.GE25335@redhat.com> <5278FE13.6030401@redhat.com> <527983E2.8000708@martos.bme.hu> <5279B4A8.3020802@redhat.com> <527A4709.7040200@martos.bme.hu> Message-ID: <527A4E34.9050905@redhat.com> On 11/06/2013 06:41 AM, Tamas Papp wrote: > > On 11/06/2013 04:16 AM, Rob Crittenden wrote: >> >>> >>>>> >>>>>> 5. If I have a network like this: >>>>>> >>>>>> A1______B1 >>>>>> A2 B2 >>>>>> >>>>>> A2 and B1,2 are replicated from A1 >>>>>> >>>>>> If the connection gets lost between A and B site, are B1 and 2 (and >>>>>> A1,2) replicated fine? >>>>> I assume from the above that B1 does not know about B2 (and vice >>>>> versa)? >>> >>> Well, that is actually one of the questions. B1 and B2 are on the same >>> sites and failover nodes from point of view of clients. >> >> You can manage the replication topology with ipa-replica-manage >> connect and disconnect. So if you want B1 and B2 connected you can >> do that. >> >>> >>>>> Once connectivity between sites A and B restored, all unreplicated >>>>> data >>>>> will be replicated. There could be conflicts if there were changes on >>>>> both sides during the split but majority of them are solved >>>>> automatically by 389-ds. >>> >>> The main question is that B1 and B2 are not replicated to each other >>> automatically? What about the case if >>> >>> A1 -- replication -- A2 --- replication --- B1 -- replication -- B2 >>> >>> If B1 gets destroyed, how B2 and A2 (and A1) gets synchronized? >>> Especially automatically...? >>> Is there such a failover configuration? >> >> No, the masters only replicate to the ones you tell them to, so if B1 >> went away forever then B2 would never get any other updates unless >> you explicitly made a connection to A1 or A2. > > Can the replication agreement be circular? > > *A2*-A1-B1-B2-*A**2*? Yes. > > > > Thanks, > tamas -------------- next part -------------- An HTML attachment was scrubbed... URL: From pablo at vdevices.com Wed Nov 6 14:20:48 2013 From: pablo at vdevices.com (Pablo Carranza) Date: Wed, 6 Nov 2013 08:20:48 -0600 Subject: [Freeipa-users] New login procedure for FreeIPA wiki - need advice! In-Reply-To: <527A3828.9080300@redhat.com> References: <527A3828.9080300@redhat.com> Message-ID: Have you guys/gals considered using Sphinx , instead (perhaps, in conjunction with ReadTheDocs.org )? The documentation source can then be hosted on GitHub. For live examples, check out: - Salt Cloud's Documentation; or - Gate One Documentation -Pablo vDevices.com | Providing Hosted IT Solutions for Lawyers & Other Mobile Professionals On Wed, Nov 6, 2013 at 6:38 AM, Dmitri Pal wrote: > Hello, > > We are trying to make access to the FreeIPA wiki easier and allow > contributions without addition overhead. In the past to make any change > to wiki one had to have a special wiki account. The procedure of > creating such account was cumbersome. We added support for OpenID. Among > available providers we selected to support Fedora accounting system at > least for now. OpenID configuration allows other providers like Google > or Yahoo but we were concerned that trusting them might allow spam bots > to connect and pollute the wiki. May be we are over cautious and we > should open up to those providers? We are seeking advice from you on > what is better. > Right now it does not allow logins with old accounts any more, only with > OpenID. Unfortunately it is all of nothing. But we do not want people > that had accounts and were able to contribute in the past but do not > have Fedora account to loose ability to contribute. > Any ideas and suggestions welcome! > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Wed Nov 6 14:33:18 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 6 Nov 2013 16:33:18 +0200 Subject: [Freeipa-users] New login procedure for FreeIPA wiki - need advice! In-Reply-To: References: <527A3828.9080300@redhat.com> Message-ID: <20131106143318.GJ25335@redhat.com> On Wed, 06 Nov 2013, Pablo Carranza wrote: >Have you guys/gals considered using Sphinx , >instead (perhaps, in conjunction with ReadTheDocs.org >)? I'm not sure how it helps -- we need a wiki working on FreeIPA org, it is part of our development routine to work jointly on feature development and we use wiki for that purpose -- see http://www.freeipa.org/page/V3_Designs We also have no need to use alternative hosting, current one is fine, so github is not really a solution. -- / Alexander Bokovoy From pviktori at redhat.com Wed Nov 6 14:50:13 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 06 Nov 2013 15:50:13 +0100 Subject: [Freeipa-users] New login procedure for FreeIPA wiki - need advice! In-Reply-To: <20131106143318.GJ25335@redhat.com> References: <527A3828.9080300@redhat.com> <20131106143318.GJ25335@redhat.com> Message-ID: <527A5725.2090308@redhat.com> On 11/06/2013 03:33 PM, Alexander Bokovoy wrote: > On Wed, 06 Nov 2013, Pablo Carranza wrote: > >> Have you guys/gals considered using Sphinx , >> instead (perhaps, in conjunction with >> ReadTheDocs.org >> )? Yes, we considered it. Sphinx and ReadTheDocs are great for a library, but we're not really making a library. The tools we have now work well for us. That said, if we wanted to document ipapython or ipaldap and make them available for projects other than IPA, I think Sphinx would be the tool to use. > I'm not sure how it helps -- we need a wiki working on FreeIPA org, it > is part of our development routine to work jointly on feature > development and we use wiki for that purpose -- see > http://www.freeipa.org/page/V3_Designs > > We also have no need to use alternative hosting, current one is fine, so > github is not really a solution. > The developer docs, HOWTOs, release info, etc. are fine on the wiki. IPA's end-user documentation is in Docbook/Publican, hosted at https://git.fedorahosted.org/git/docs/freeipa-guide.git -- once we make it presentable we'll host the built docs on freeipa.org as well. (Of course it's a Git repo, anyone is free to make a mirror on Github. I'm sure you can find one :P) -- Petr? From rmcasey at sei.cmu.edu Wed Nov 6 15:03:11 2013 From: rmcasey at sei.cmu.edu (Ryan M. Casey) Date: Wed, 6 Nov 2013 15:03:11 +0000 Subject: [Freeipa-users] OpenLDAP migration issues Message-ID: <659356A01DEDDE41B1F25926C2570894271BB53E@marathon> I'm attempting to migrate our OpenLDAP+Kerberos authentication scheme to FreeIPA. Running the following migration command: ipa migrate-ds --bind-dn="cn=admin,dc=foo,dc=com" --base-dn="dc=foo,dc=com" --user-container="ou=users" --group-container="ou=group" --user-objectclass="posixAccount" --group-objectclass="posixGroup" ldap://ldap.foo.com results in this error in/var/log/httpd/error_log: ValueError: unable to convert the attribute "krbPrincipalKey" value I've tried to exclude the attribute using -user-attribute-ignore=krbPrincipalKey, but am still receiving the same error message. Our server is running Fedora 19 with the latest version of FreeIPA available. Anyone have any ideas on how I can resolve this? -Ryan -------------- next part -------------- An HTML attachment was scrubbed... URL: From Mike.Calautti at genesyslab.com Wed Nov 6 15:27:18 2013 From: Mike.Calautti at genesyslab.com (Mike Calautti) Date: Wed, 6 Nov 2013 15:27:18 +0000 Subject: [Freeipa-users] trying to setup cert with an internal CA Message-ID: <37D7774D237F0F4FA1CC50B5FE41FBD51AF9AD@GENSJZMBX03.msg.int.genesyslab.com> Hi, We have our own in house CA>. I ran ipa-server-install -a secret12 -r EXAMPLE.COM -P password -p secret12 -n ipaserver.example.com --external-ca It generated ipa.csr as expected.. I used opsenssl to sign it on our internal CA. I got the .crt file.. I assume I need the private KEY that the IPA server generated when it did the install.. and I assume I need ipa-getcert command to find it? I cant seem to find it.. I am doing this because I assume I have to combine the CA files into a chain file and convert them to .p12 format? This is on Linux rdsdev01.com 3.4.61-9.el6.centos.alt.x86_64 #1 SMP Wed Sep 11 15:34:17 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux cat /etc/redhat-release CentOS release 6.4 (Final) rpm -qav|grep -i ipa ipa-python-3.0.0-26.el6_4.4.x86_64 ipa-server-selinux-3.0.0-26.el6_4.4.x86_64 ipa-pki-ca-theme-9.0.3-7.el6.noarch libipa_hbac-1.9.2-82.10.el6_4.x86_64 libipa_hbac-python-1.9.2-82.10.el6_4.x86_64 ipa-client-3.0.0-26.el6_4.4.x86_64 ipa-server-3.0.0-26.el6_4.4.x86_64 ipa-pki-common-theme-9.0.3-7.el6.noarch ipa-admintools-3.0.0-26.el6_4.4.x86_64 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Wed Nov 6 15:35:55 2013 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 06 Nov 2013 10:35:55 -0500 Subject: [Freeipa-users] OpenLDAP migration issues In-Reply-To: <659356A01DEDDE41B1F25926C2570894271BB53E@marathon> References: <659356A01DEDDE41B1F25926C2570894271BB53E@marathon> Message-ID: <527A61DB.2070600@redhat.com> On 11/06/2013 10:03 AM, Ryan M. Casey wrote: > > I'm attempting to migrate our OpenLDAP+Kerberos authentication scheme > to FreeIPA. Running the following migration command: > > > > ipa migrate-ds --bind-dn="cn=admin,dc=foo,dc=com" > --base-dn="dc=foo,dc=com" --user-container="ou=users" > --group-container="ou=group" --user-objectclass="posixAccount" > --group-objectclass="posixGroup" ldap://ldap.foo.com > > > > results in this error in/var/log/httpd/error_log: > > > > ValueError: unable to convert the attribute "krbPrincipalKey" value > > > > I've tried to exclude the attribute using > --user-attribute-ignore=krbPrincipalKey, but am still receiving the > same error message. Our server is running Fedora 19 with the latest > version of FreeIPA available. Anyone have any ideas on how I can > resolve this? > > > I think a snippet from the log might shed more light. Kerberos logs also might be valuable. Can it be that the kerberos key is an old weak crypto that we reject by default? May be setting allow_weak_crypto = true in krb5.conf on the server would help? > -Ryan > > > > > > _______________________________________________ > 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 Nov 6 15:39:25 2013 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 06 Nov 2013 10:39:25 -0500 Subject: [Freeipa-users] rhel 5 client in a rhel 6 domain? In-Reply-To: References: <1374510726.4906.6.camel@localhost.localdomain> <51ED6ECB.40208@redhat.com> <1374515508.4906.8.camel@localhost.localdomain> <1374524920.4906.11.camel@localhost.localdomain> <51EDA8E2.4090702@redhat.com> <1374585781.8235.1.camel@localhost.localdomain> <1374599628.8235.8.camel@localhost.localdomain> <1374603722.8235.11.camel@localhost.localdomain> <51EFD88D.9040304@redhat.com> <1374674942.7479.1.camel@localhost.localdomain> Message-ID: <527A62AD.10202@redhat.com> On 11/06/2013 12:15 AM, indira wrote: > Armstrong, Kenneth Lawrence writes: > > > > hi.. > has the problem fixed??? > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users Was a ticket filed? -- 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 Wed Nov 6 16:01:43 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 06 Nov 2013 11:01:43 -0500 Subject: [Freeipa-users] OpenLDAP migration issues In-Reply-To: <659356A01DEDDE41B1F25926C2570894271BB53E@marathon> References: <659356A01DEDDE41B1F25926C2570894271BB53E@marathon> Message-ID: <527A67E7.8060505@redhat.com> Ryan M. Casey wrote: > I?m attempting to migrate our OpenLDAP+Kerberos authentication scheme to > FreeIPA. Running the following migration command: > > ipa migrate-ds --bind-dn="cn=admin,dc=foo,dc=com" > --base-dn="dc=foo,dc=com" --user-container="ou=users" > --group-container="ou=group" --user-objectclass="posixAccount" > --group-objectclass="posixGroup" ldap://ldap.foo.com > > results in this error in/var/log/httpd/error_log: > > ValueError: unable to convert the attribute "krbPrincipalKey" value > > I?ve tried to exclude the attribute using > ?user-attribute-ignore=krbPrincipalKey, but am still receiving the same > error message. Our server is running Fedora 19 with the latest version > of FreeIPA available. Anyone have any ideas on how I can resolve this? I think that IPA is having an issue with the data in your LDAP server, at least for one record. I think in this case the syntax of the entry doesn't match what we expect it to be. The ignore is applied after reading in the remote entry, so if we can't understand it then it never gets far enough to ignore it. This is being looked at in development versions. So I think the first step would be to find the offending entry. rob From rcritten at redhat.com Wed Nov 6 16:05:46 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 06 Nov 2013 11:05:46 -0500 Subject: [Freeipa-users] trying to setup cert with an internal CA In-Reply-To: <37D7774D237F0F4FA1CC50B5FE41FBD51AF9AD@GENSJZMBX03.msg.int.genesyslab.com> References: <37D7774D237F0F4FA1CC50B5FE41FBD51AF9AD@GENSJZMBX03.msg.int.genesyslab.com> Message-ID: <527A68DA.10508@redhat.com> Mike Calautti wrote: > Hi, > > We have our own in house CA>. > > I ran ipa-server-install -a secret12 -r EXAMPLE.COM -P password -p > secret12 -n ipaserver.example.com --external-ca > > It generated ipa.csr as expected.. > > I used opsenssl to sign it on our internal CA. I got the .crt file.. > > I assume I need the private KEY that the IPA server generated when it > did the install.. and I assume I need ipa-getcert command to find it? No, you just need to re-run the installer with --external_cert_file=/path/to/server.pem --external_ca_file=/path/to/external_ca.pem The installer will pick up where it left off and finish installing the CA and the other IPA components. rob > I cant seem to find it.. I am doing this because I assume I have to > combine the CA files into a chain file and convert them to .p12 format? > > This is on > > Linux rdsdev01.com 3.4.61-9.el6.centos.alt.x86_64 #1 SMP Wed Sep 11 > 15:34:17 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux > > cat /etc/redhat-release > > CentOS release 6.4 (Final) > > rpm -qav|grep -i ipa > > ipa-python-3.0.0-26.el6_4.4.x86_64 > > ipa-server-selinux-3.0.0-26.el6_4.4.x86_64 > > ipa-pki-ca-theme-9.0.3-7.el6.noarch > > libipa_hbac-1.9.2-82.10.el6_4.x86_64 > > libipa_hbac-python-1.9.2-82.10.el6_4.x86_64 > > ipa-client-3.0.0-26.el6_4.4.x86_64 > > ipa-server-3.0.0-26.el6_4.4.x86_64 > > ipa-pki-common-theme-9.0.3-7.el6.noarch > > ipa-admintools-3.0.0-26.el6_4.4.x86_64 > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > From abontempi at dbmsrl.com Wed Nov 6 16:45:29 2013 From: abontempi at dbmsrl.com (Andrea Bontempi) Date: Wed, 6 Nov 2013 17:45:29 +0100 (CET) Subject: [Freeipa-users] Installation issues with sub-ca. In-Reply-To: <1308542690.35028.1383755712023.JavaMail.root@dbmsrl.com> Message-ID: <1008786015.35062.1383756329711.JavaMail.root@dbmsrl.com> Hi, i'm trying to install FreeIPA with an external CA, but the installation script throws this error: CalledProcessError: Command '/usr/bin/sslget -v -n ipa-ca-agent -p XXXXXXXX -d /tmp/tmp-rrhisg -r /ca/agent/ca/profileReview?requestId=6 ipa.dbmsrl.com:9443' returned non-zero exit status 4 Here the log file: http://pastebin.com/wCGUdu7h The server is a CentOS Linux 2.6.32-358.23.2.el6.x86_64 and i use FreeIPA 3.0.0 Can someone help me? Thank you From rcritten at redhat.com Wed Nov 6 16:57:32 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 06 Nov 2013 11:57:32 -0500 Subject: [Freeipa-users] Installation issues with sub-ca. In-Reply-To: <1008786015.35062.1383756329711.JavaMail.root@dbmsrl.com> References: <1008786015.35062.1383756329711.JavaMail.root@dbmsrl.com> Message-ID: <527A74FC.5050501@redhat.com> Andrea Bontempi wrote: > Hi, > > i'm trying to install FreeIPA with an external CA, but the installation script throws this error: > > CalledProcessError: Command '/usr/bin/sslget -v -n ipa-ca-agent -p XXXXXXXX -d /tmp/tmp-rrhisg -r /ca/agent/ca/profileReview?requestId=6 ipa.dbmsrl.com:9443' returned non-zero exit status 4 > > Here the log file: http://pastebin.com/wCGUdu7h > > The server is a CentOS Linux 2.6.32-358.23.2.el6.x86_64 and i use FreeIPA 3.0.0 > > Can someone help me? > -12195 is SSL_ERROR_UNKNOWN_CA_ALERT in NSS. I wonder if the root chain you gave to the IPA installer was complete. rob From nkinder at redhat.com Wed Nov 6 23:23:51 2013 From: nkinder at redhat.com (Nathan Kinder) Date: Wed, 06 Nov 2013 15:23:51 -0800 Subject: [Freeipa-users] Revisiting ILO In-Reply-To: References: Message-ID: <527ACF87.8020701@redhat.com> On 11/05/2013 11:51 AM, KodaK wrote: > If I use the whole connection string: > > uid=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com > > I can authenticate. The HP iLO documentation doesn't list using the uid value as a supported form of specifying the login. You can use the CN value or the full DN. They say that "DOMAIN\user" and "user at domain" forms are also accepted, but that likely only works against Active Directory. -NGK > > > On Tue, Nov 5, 2013 at 1:40 PM, KodaK > wrote: > > I'm attempting to get HP ILO authenticating against IPA again. > > I've configured the user context in ILO as: > > cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com > > When ILO tries to connect, it sends the string: > > CN=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com > > Which, of course, doesn't exist. IPA uses uid=, but as > far as I can tell I can't tell ILO to use a different username > attribute. It doesn't even look like it's trying to use a > username attribute. > > I've tried to force it to look for uid=jebalicki by using > "uid=jebalicki" in the login field, but that fails too. The > errors in the errors log look like this: > > > [05/Nov/2013:13:22:05 -0600] ipalockout_preop - [file > ipa_lockout.c, line 645]: Failed to retrieve entry "jebalicki": 32 > [05/Nov/2013:13:22:05 -0600] ipalockout_postop - [file > ipa_lockout.c, line 421]: Failed to retrieve entry "jebalicki": 32 > [05/Nov/2013:13:22:05 -0600] ipalockout_preop - [file > ipa_lockout.c, line 645]: Failed to retrieve entry > "CN=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com": > 32 > [05/Nov/2013:13:22:05 -0600] ipalockout_postop - [file > ipa_lockout.c, line 421]: Failed to retrieve entry > "CN=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com": > 32 > [05/Nov/2013:13:22:05 -0600] ipalockout_preop - [file > ipa_lockout.c, line 645]: Failed to retrieve entry "jebalicki": 32 > [05/Nov/2013:13:22:05 -0600] ipalockout_postop - [file > ipa_lockout.c, line 421]: Failed to retrieve entry "jebalicki": 32 > [05/Nov/2013:13:22:05 -0600] ipalockout_preop - [file > ipa_lockout.c, line 645]: Failed to retrieve entry > "CN=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com": > 32 > [05/Nov/2013:13:22:05 -0600] ipalockout_postop - [file > ipa_lockout.c, line 421]: Failed to retrieve entry > "CN=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com": > 32 > [05/Nov/2013:13:22:05 -0600] ipalockout_preop - [file > ipa_lockout.c, line 645]: Failed to retrieve entry "jebalicki": 32 > [05/Nov/2013:13:22:05 -0600] ipalockout_postop - [file > ipa_lockout.c, line 421]: Failed to retrieve entry "jebalicki": 32 > [05/Nov/2013:13:22:05 -0600] ipalockout_preop - [file > ipa_lockout.c, line 645]: Failed to retrieve entry > "CN=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com": > 32 > [05/Nov/2013:13:22:05 -0600] ipalockout_postop - [file > ipa_lockout.c, line 421]: Failed to retrieve entry > "CN=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com": > 32 > [05/Nov/2013:13:27:39 -0600] ipalockout_preop - [file > ipa_lockout.c, line 645]: Failed to retrieve entry "uid=jebalicki": 32 > [05/Nov/2013:13:27:39 -0600] ipalockout_postop - [file > ipa_lockout.c, line 421]: Failed to retrieve entry "uid=jebalicki": 32 > [05/Nov/2013:13:27:39 -0600] ipalockout_preop - [file > ipa_lockout.c, line 645]: Failed to retrieve entry > "CN=uid=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com": > 32 > [05/Nov/2013:13:27:39 -0600] ipalockout_postop - [file > ipa_lockout.c, line 421]: Failed to retrieve entry > "CN=uid=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com": > 32 > [05/Nov/2013:13:27:39 -0600] ipalockout_preop - [file > ipa_lockout.c, line 645]: Failed to retrieve entry "uid=jebalicki": 32 > [05/Nov/2013:13:27:39 -0600] ipalockout_postop - [file > ipa_lockout.c, line 421]: Failed to retrieve entry "uid=jebalicki": 32 > [05/Nov/2013:13:27:39 -0600] ipalockout_preop - [file > ipa_lockout.c, line 645]: Failed to retrieve entry > "CN=uid=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com": > 32 > [05/Nov/2013:13:27:39 -0600] ipalockout_postop - [file > ipa_lockout.c, line 421]: Failed to retrieve entry > "CN=uid=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com": > 32 > [05/Nov/2013:13:27:39 -0600] ipalockout_preop - [file > ipa_lockout.c, line 645]: Failed to retrieve entry "uid=jebalicki": 32 > [05/Nov/2013:13:27:39 -0600] ipalockout_postop - [file > ipa_lockout.c, line 421]: Failed to retrieve entry "uid=jebalicki": 32 > [05/Nov/2013:13:27:39 -0600] ipalockout_preop - [file > ipa_lockout.c, line 645]: Failed to retrieve entry > "CN=uid=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com": > 32 > [05/Nov/2013:13:27:39 -0600] ipalockout_postop - [file > ipa_lockout.c, line 421]: Failed to retrieve entry > "CN=uid=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com": > 32 > > And the access log looks like this: > > [05/Nov/2013:13:32:06 -0600] conn=214941 fd=438 slot=438 SSL > connection from 10.200.10.192 to 10.200.16.170 > [05/Nov/2013:13:32:06 -0600] conn=214941 SSL 256-bit AES > [05/Nov/2013:13:32:06 -0600] conn=214941 op=0 BIND > dn="uid=jebalicki" method=128 version=2 > [05/Nov/2013:13:32:06 -0600] conn=214941 op=0 RESULT err=32 tag=97 > nentries=0 etime=0 > [05/Nov/2013:13:32:06 -0600] conn=214941 op=1 BIND > dn="CN=uid=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com" > method=128 version=2 > [05/Nov/2013:13:32:07 -0600] conn=214941 op=1 RESULT err=32 tag=97 > nentries=0 etime=1 > [05/Nov/2013:13:32:07 -0600] conn=214941 op=2 UNBIND > [05/Nov/2013:13:32:07 -0600] conn=214941 op=2 fd=438 closed - U1 > [05/Nov/2013:13:32:07 -0600] conn=214942 fd=439 slot=439 SSL > connection from 10.200.10.192 to 10.200.16.170 > [05/Nov/2013:13:32:07 -0600] conn=214942 SSL 256-bit AES > [05/Nov/2013:13:32:07 -0600] conn=214942 op=0 BIND > dn="uid=jebalicki" method=128 version=2 > [05/Nov/2013:13:32:07 -0600] conn=214942 op=0 RESULT err=32 tag=97 > nentries=0 etime=0 > [05/Nov/2013:13:32:07 -0600] conn=214942 op=1 UNBIND > [05/Nov/2013:13:32:07 -0600] conn=214942 op=1 fd=439 closed - U1 > [05/Nov/2013:13:32:07 -0600] conn=214943 fd=438 slot=438 SSL > connection from 10.200.10.192 to 10.200.16.170 > [05/Nov/2013:13:32:07 -0600] conn=214943 SSL 256-bit AES > [05/Nov/2013:13:32:07 -0600] conn=214943 op=0 BIND > dn="CN=uid=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com" > method=128 version=2 > [05/Nov/2013:13:32:07 -0600] conn=214943 op=0 RESULT err=32 tag=97 > nentries=0 etime=0 > [05/Nov/2013:13:32:07 -0600] conn=214943 op=1 UNBIND > [05/Nov/2013:13:32:07 -0600] conn=214943 op=1 fd=438 closed - U1 > > Is there any way to force things on the IPA side? Can I > automatically attach on the necessary components to the provided > username? > > > > > -- > The government is going to read our mail anyway, might as well make it > tough for them. GPG Public key ID: B6A1A7C6 > > > _______________________________________________ > 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 deanhunter at comcast.net Thu Nov 7 04:13:42 2013 From: deanhunter at comcast.net (Dean Hunter) Date: Wed, 06 Nov 2013 22:13:42 -0600 Subject: [Freeipa-users] reboot required after ipa-client-install? Message-ID: <1383797622.19912.34.camel@host.hunter.org> After building a new VM and configuring the IPA 3.3.2 client, Gnome seems to only perform a local log-in until the system is rebooted. SSH works with IPA, but not Gnome. Is this correct? Is there anything less disruptive than a reboot that I can do? -------------- next part -------------- An HTML attachment was scrubbed... URL: From arthur at deus.pro Thu Nov 7 04:49:09 2013 From: arthur at deus.pro (Arthur Faizullin) Date: Thu, 07 Nov 2013 10:49:09 +0600 Subject: [Freeipa-users] question about generating certificates In-Reply-To: <20131106125201.GI25335@redhat.com> References: <1383725778.3819.15.camel@coruscant.bashnl.ru> <1383739262.3819.41.camel@coruscant.bashnl.ru> <20131106125201.GI25335@redhat.com> Message-ID: <1383799749.3819.48.camel@coruscant.bashnl.ru> ? ??, 06/11/2013 ? 14:52 +0200, Alexander Bokovoy ?????: > On Wed, 06 Nov 2013, Arthur Faizullin wrote: > >????? ??????? ??????????? has give me advise that the > >problem may be in Selinux. > >so I has stoped tracking previous request by > >$ sudo ipa-getcert stop-tracking -i 20131106075356 > > > >and has generated new request > ># ipa-getcert request -f /var/lib/certmonger/requests/server.crt > >-k /var/lib/certmonger/requests/server.key -K > >postgresql/postgresql.example.com -N CN=postgresql.example.com -D > >postgresql.example.com > > > >that made desired files to appear at /var/lib/certmonger/requests/ > >that is okay! :) > >but! I want them in /var/lib/pgsql/9.3/data/ > >so what is the problem? why not just copy them at that directory? > >the problem is that when I list cert requests, I see this: > >Request ID '20131106113520': > > status: MONITORING > > stuck: no > > key pair storage: > >type=FILE,location='/var/lib/certmonger/requests/server.key' > > certificate: > >type=FILE,location='/var/lib/certmonger/requests/server.crt' > > CA: IPA > > issuer: CN=Certificate Authority,O=EXAMPLE.COM > > subject: CN=postgresql.example.com,O=EXAMPLE.COM > > expires: 2015-11-07 11:35:20 UTC > > eku: id-kp-serverAuth,id-kp-clientAuth > > pre-save command: > > post-save command: > > track: yes > > auto-renew: yes > > > >we can see that file location in that list is defined at request time. > > > >Shall I make Selinux to let certmonger to access /var/lib/pgsql ? or is > >there any other solution? > certmonger does run under certmonger_t SELinux type and system_r role. > It can already write to file contexts named certmonger_*_t and cert_t. For > storing certificates you would need to use cert_t file context. > > mkdir -p /var/lib/pgsql/9.3/data/certs > semanage fcontext -a -t cert_t '/var/lib/pgsql/9.3/data/certs(/.*)?' > restorecon -R -v /var/lib/pgsql/9.3/data/certs > > I would advise you against placing the files directly in > /var/lib/pgsql/9.3/data as opposed to the subdirectory. It is safer to > specify path to the certificate in pgsql configuration. I have tried it, but I still get this answer: # ipa-getcert request -f /var/lib/pgsql/9.3/data/certs/server.crt -k /var/lib/pgsql/9.3/data/certs/server.key -K postgresql/postgresql.example.com -N CN=postgresql.example.com -D postgresql.example.com The parent of location "/var/lib/pgsql/9.3/data/certs/server.crt" must be a valid directory. What does "valid directory" mean? > > >And I think that there mast be note at documentation about such > >situations with Selinux. > Yes. You can also install selinux-policy-devel package and read > certmonger_selinux (8) manpage. > > Can you open a ticket against FreeIPA documentation. Is bug opened by Dmitri Pal enough? https://bugzilla.redhat.com/show_bug.cgi?id=1027265 > From arthur at deus.pro Thu Nov 7 04:53:54 2013 From: arthur at deus.pro (Arthur Faizullin) Date: Thu, 07 Nov 2013 10:53:54 +0600 Subject: [Freeipa-users] question about generating certificates In-Reply-To: <527A47A0.7050706@redhat.com> References: <1383725778.3819.15.camel@coruscant.bashnl.ru> <1383739262.3819.41.camel@coruscant.bashnl.ru> <527A3C51.6050100@redhat.com> <527A47A0.7050706@redhat.com> Message-ID: <1383800034.3819.51.camel@coruscant.bashnl.ru> ? ??, 06/11/2013 ? 08:44 -0500, Rob Crittenden ?????: > Dmitri Pal wrote: > > On 11/06/2013 07:01 AM, Arthur Faizullin wrote: > >> ????? ??????? ??????????? has give me advise that the > >> problem may be in Selinux. > >> so I has stoped tracking previous request by > >> $ sudo ipa-getcert stop-tracking -i 20131106075356 > >> > >> and has generated new request > >> # ipa-getcert request -f /var/lib/certmonger/requests/server.crt > >> -k /var/lib/certmonger/requests/server.key -K > >> postgresql/postgresql.example.com -N CN=postgresql.example.com -D > >> postgresql.example.com > >> > >> that made desired files to appear at /var/lib/certmonger/requests/ > >> that is okay! :) > >> but! I want them in /var/lib/pgsql/9.3/data/ > >> so what is the problem? why not just copy them at that directory? > >> the problem is that when I list cert requests, I see this: > >> Request ID '20131106113520': > >> status: MONITORING > >> stuck: no > >> key pair storage: > >> type=FILE,location='/var/lib/certmonger/requests/server.key' > >> certificate: > >> type=FILE,location='/var/lib/certmonger/requests/server.crt' > >> CA: IPA > >> issuer: CN=Certificate Authority,O=EXAMPLE.COM > >> subject: CN=postgresql.example.com,O=EXAMPLE.COM > >> expires: 2015-11-07 11:35:20 UTC > >> eku: id-kp-serverAuth,id-kp-clientAuth > >> pre-save command: > >> post-save command: > >> track: yes > >> auto-renew: yes > >> > >> we can see that file location in that list is defined at request time. > >> > >> Shall I make Selinux to let certmonger to access /var/lib/pgsql ? or is > >> there any other solution? > > > > I think yes. And I recall this is not the first time this comes up. > > My memory might be failing me but I vaguely remember that we discussed this. > > However I could not find any bug or ticket on the matter so I created this > > https://bugzilla.redhat.com/show_bug.cgi?id=1027265 > > Typically in Fedora and RHEL certs are expected to go into > /etc/pki/tls/certs and keys into /etc/pki/tls/private. These directories > have the correct SELinux contexts. > > rob as with krb5 keytab, which recomended to keep in specified directory https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/services.html I thought that ssl keys also should be keeped in specified directory. > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From arthur at deus.pro Thu Nov 7 06:27:58 2013 From: arthur at deus.pro (Arthur Faizullin) Date: Thu, 07 Nov 2013 12:27:58 +0600 Subject: [Freeipa-users] question about generating certificates In-Reply-To: <1383800034.3819.51.camel@coruscant.bashnl.ru> References: <1383725778.3819.15.camel@coruscant.bashnl.ru> <1383739262.3819.41.camel@coruscant.bashnl.ru> <527A3C51.6050100@redhat.com> <527A47A0.7050706@redhat.com> <1383800034.3819.51.camel@coruscant.bashnl.ru> Message-ID: <1383805678.3819.60.camel@coruscant.bashnl.ru> I have done as You said! # ipa-getcert request -f /etc/pki/tls/certs/postgresql.crt -k /etc/pki/tls/private/postgresql.key -K postgresql/postgresql.example.com -N CN=postgresql.example.com -D postgresql.example.com # ipa-getcert list Request ID '20131107050729': status: MONITORING stuck: no key pair storage: type=FILE,location='/etc/pki/tls/private/postgresql.key' certificate: type=FILE,location='/etc/pki/tls/certs/postgresql.crt' CA: IPA issuer: CN=Certificate Authority,O=EXAMPLE.COM subject: CN=postgresql.example.com,O=EXAMPLE.COM expires: 2015-11-08 05:07:29 UTC eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes at startup a get such errors: < 2013-11-07 12:06:58.997 YEKT >FATAL: could not load server certificate file "/etc/pki/tls/certs/postgresql.crt": Permission denied < 2013-11-07 12:10:23.550 YEKT >FATAL: could not load server certificate file "/etc/pki/tls/certs/postgresql.crt": Permission denied but after I've changed owner: # chown postgres /etc/pki/tls/certs/postgresql.crt # chown postgres /etc/pki/tls/private/postgresql.key # ll /etc/pki/tls/certs/postgresql.crt -rw-------. 1 postgres root 1318 ??? 7 11:07 /etc/pki/tls/certs/postgresql.crt # ll /etc/pki/tls/private/postgresql.key -rw-------. 1 postgres root 1704 ??? 7 11:07 /etc/pki/tls/private/postgresql.key it seems to be starting well! But since I've changed the owner of key-file and certificate-file will certmonger still be monitoring these files? ? ??, 07/11/2013 ? 10:53 +0600, Arthur Faizullin ?????: > ? ??, 06/11/2013 ? 08:44 -0500, Rob Crittenden ?????: > > Dmitri Pal wrote: > > > On 11/06/2013 07:01 AM, Arthur Faizullin wrote: > > >> ????? ??????? ??????????? has give me advise that the > > >> problem may be in Selinux. > > >> so I has stoped tracking previous request by > > >> $ sudo ipa-getcert stop-tracking -i 20131106075356 > > >> > > >> and has generated new request > > >> # ipa-getcert request -f /var/lib/certmonger/requests/server.crt > > >> -k /var/lib/certmonger/requests/server.key -K > > >> postgresql/postgresql.example.com -N CN=postgresql.example.com -D > > >> postgresql.example.com > > >> > > >> that made desired files to appear at /var/lib/certmonger/requests/ > > >> that is okay! :) > > >> but! I want them in /var/lib/pgsql/9.3/data/ > > >> so what is the problem? why not just copy them at that directory? > > >> the problem is that when I list cert requests, I see this: > > >> Request ID '20131106113520': > > >> status: MONITORING > > >> stuck: no > > >> key pair storage: > > >> type=FILE,location='/var/lib/certmonger/requests/server.key' > > >> certificate: > > >> type=FILE,location='/var/lib/certmonger/requests/server.crt' > > >> CA: IPA > > >> issuer: CN=Certificate Authority,O=EXAMPLE.COM > > >> subject: CN=postgresql.example.com,O=EXAMPLE.COM > > >> expires: 2015-11-07 11:35:20 UTC > > >> eku: id-kp-serverAuth,id-kp-clientAuth > > >> pre-save command: > > >> post-save command: > > >> track: yes > > >> auto-renew: yes > > >> > > >> we can see that file location in that list is defined at request time. > > >> > > >> Shall I make Selinux to let certmonger to access /var/lib/pgsql ? or is > > >> there any other solution? > > > > > > I think yes. And I recall this is not the first time this comes up. > > > My memory might be failing me but I vaguely remember that we discussed this. > > > However I could not find any bug or ticket on the matter so I created this > > > https://bugzilla.redhat.com/show_bug.cgi?id=1027265 > > > > Typically in Fedora and RHEL certs are expected to go into > > /etc/pki/tls/certs and keys into /etc/pki/tls/private. These directories > > have the correct SELinux contexts. > > > > rob > > as with krb5 keytab, which recomended to keep in specified directory > https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/services.html > I thought that ssl keys also should be keeped in specified directory. > > > > > _______________________________________________ > > 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 arthur at deus.pro Thu Nov 7 06:33:28 2013 From: arthur at deus.pro (Arthur Faizullin) Date: Thu, 07 Nov 2013 12:33:28 +0600 Subject: [Freeipa-users] question about generating certificates In-Reply-To: <1383799749.3819.48.camel@coruscant.bashnl.ru> References: <1383725778.3819.15.camel@coruscant.bashnl.ru> <1383739262.3819.41.camel@coruscant.bashnl.ru> <20131106125201.GI25335@redhat.com> <1383799749.3819.48.camel@coruscant.bashnl.ru> Message-ID: <1383806008.3819.65.camel@coruscant.bashnl.ru> I have found what that means. It is again something with access rights. Rob Crittenden says that it is better to generate certificates at: /etc/pki/tls/private/postgresql.key /etc/pki/tls/certs/postgresql.crt and if these files owner is postgres then postgresql is starting well, but I do not know if certmonger will keep be tracking these file in case of owner changed. ? ??, 07/11/2013 ? 10:49 +0600, Arthur Faizullin ?????: > ? ??, 06/11/2013 ? 14:52 +0200, Alexander Bokovoy ?????: > > On Wed, 06 Nov 2013, Arthur Faizullin wrote: > > >????? ??????? ??????????? has give me advise that the > > >problem may be in Selinux. > > >so I has stoped tracking previous request by > > >$ sudo ipa-getcert stop-tracking -i 20131106075356 > > > > > >and has generated new request > > ># ipa-getcert request -f /var/lib/certmonger/requests/server.crt > > >-k /var/lib/certmonger/requests/server.key -K > > >postgresql/postgresql.example.com -N CN=postgresql.example.com -D > > >postgresql.example.com > > > > > >that made desired files to appear at /var/lib/certmonger/requests/ > > >that is okay! :) > > >but! I want them in /var/lib/pgsql/9.3/data/ > > >so what is the problem? why not just copy them at that directory? > > >the problem is that when I list cert requests, I see this: > > >Request ID '20131106113520': > > > status: MONITORING > > > stuck: no > > > key pair storage: > > >type=FILE,location='/var/lib/certmonger/requests/server.key' > > > certificate: > > >type=FILE,location='/var/lib/certmonger/requests/server.crt' > > > CA: IPA > > > issuer: CN=Certificate Authority,O=EXAMPLE.COM > > > subject: CN=postgresql.example.com,O=EXAMPLE.COM > > > expires: 2015-11-07 11:35:20 UTC > > > eku: id-kp-serverAuth,id-kp-clientAuth > > > pre-save command: > > > post-save command: > > > track: yes > > > auto-renew: yes > > > > > >we can see that file location in that list is defined at request time. > > > > > >Shall I make Selinux to let certmonger to access /var/lib/pgsql ? or is > > >there any other solution? > > certmonger does run under certmonger_t SELinux type and system_r role. > > It can already write to file contexts named certmonger_*_t and cert_t. For > > storing certificates you would need to use cert_t file context. > > > > mkdir -p /var/lib/pgsql/9.3/data/certs > > semanage fcontext -a -t cert_t '/var/lib/pgsql/9.3/data/certs(/.*)?' > > restorecon -R -v /var/lib/pgsql/9.3/data/certs > > > > I would advise you against placing the files directly in > > /var/lib/pgsql/9.3/data as opposed to the subdirectory. It is safer to > > specify path to the certificate in pgsql configuration. > > I have tried it, but I still get this answer: > # ipa-getcert request -f /var/lib/pgsql/9.3/data/certs/server.crt > -k /var/lib/pgsql/9.3/data/certs/server.key -K > postgresql/postgresql.example.com -N CN=postgresql.example.com -D > postgresql.example.com > The parent of location "/var/lib/pgsql/9.3/data/certs/server.crt" must > be a valid directory. > > What does "valid directory" mean? > > > > > >And I think that there mast be note at documentation about such > > >situations with Selinux. > > Yes. You can also install selinux-policy-devel package and read > > certmonger_selinux (8) manpage. > > > > Can you open a ticket against FreeIPA documentation. > > Is bug opened by Dmitri Pal enough? > https://bugzilla.redhat.com/show_bug.cgi?id=1027265 > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From william.leese at meltwater.com Thu Nov 7 07:34:40 2013 From: william.leese at meltwater.com (William Leese) Date: Thu, 7 Nov 2013 16:34:40 +0900 Subject: [Freeipa-users] External CA In-Reply-To: <527A47AE.9070607@redhat.com> References: <527A47AE.9070607@redhat.com> Message-ID: > [root at vagrant-centos-6 CA]# cat /root/server.pem >> Certificate: >> Data: >> Version: 3 (0x2) >> Serial Number: 2 (0x2) >> Signature Algorithm: sha1WithRSAEncryption >> Issuer: C=JP, ST=TK, L=TKK, O=MW, OU=ops, >> CN=vagrant.localdomain/emailAddress=t at t.com >> >> Validity >> Not Before: Nov 6 05:12:09 2013 GMT >> Not After : Nov 6 05:12:09 2014 GMT >> Subject: O=MELTWATER.COM , CN=Certificate >> >> Authority >> [snip] >> -----BEGIN CERTIFICATE----- >> MIIDfDCCAmSgAwIBAgIBAjANBgkqhkiG9w0BAQUFADB5MQswCQYDVQQGEwJKUDEL >> MAkGA1UECAwCVEsxDDAKBgNVBAcMA1RLSzELMAkGA1UECgwCTVcxDDAKBgNVBAsM >> A29wczEcMBoGA1UEAwwTdmFncmFudC5sb2NhbGRvbWFpbjEWMBQGCSqGSIb3DQEJ >> [snip] >> > > Try removing everything before the -----BEGIN CERTIFICATE----- line from > the PEM. Well that was unexpected: removing the BEGIN Certificate / End lines now makes the install proceed up until: The log file for this installation can be found in /var/log/ipaserver-install.log The PKCS#10 certificate is not signed by the external CA (unknown issuer E= x at x.com,CN=vagrant-centos-6,OU=JP,O=JP,L=JP,ST=JP,C=JP). Do I need to do anything to make my freshly created internal CA trusted for the installation? I've tried the usual magic in /etc/pki/tls/certs, but to no avail. -------------- next part -------------- An HTML attachment was scrubbed... URL: From arthur at deus.pro Thu Nov 7 07:42:23 2013 From: arthur at deus.pro (Arthur Faizullin) Date: Thu, 07 Nov 2013 13:42:23 +0600 Subject: [Freeipa-users] reboot required after ipa-client-install? In-Reply-To: <1383797622.19912.34.camel@host.hunter.org> References: <1383797622.19912.34.camel@host.hunter.org> Message-ID: <1383810143.3819.67.camel@coruscant.bashnl.ru> I have not rebooted whale machine. everything worked fine. May be just try to restart gdm? # systemctl restart gdm.service ? ??, 06/11/2013 ? 22:13 -0600, Dean Hunter ?????: > After building a new VM and configuring the IPA 3.3.2 client, Gnome > seems to only perform a local log-in until the system is rebooted. SSH > works with IPA, but not Gnome. Is this correct? Is there anything less > disruptive than a reboot that I can do? > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From abokovoy at redhat.com Thu Nov 7 07:44:21 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 7 Nov 2013 09:44:21 +0200 Subject: [Freeipa-users] reboot required after ipa-client-install? In-Reply-To: <1383797622.19912.34.camel@host.hunter.org> References: <1383797622.19912.34.camel@host.hunter.org> Message-ID: <20131107074421.GL25335@redhat.com> On Wed, 06 Nov 2013, Dean Hunter wrote: >After building a new VM and configuring the IPA 3.3.2 client, Gnome >seems to only perform a local log-in until the system is rebooted. SSH >works with IPA, but not Gnome. Is this correct? Is there anything less >disruptive than a reboot that I can do? Restart gdm.service? I'm not sure how gdm handles PAM auth. -- / Alexander Bokovoy From jhrozek at redhat.com Thu Nov 7 08:39:31 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 7 Nov 2013 09:39:31 +0100 Subject: [Freeipa-users] reboot required after ipa-client-install? In-Reply-To: <20131107074421.GL25335@redhat.com> References: <1383797622.19912.34.camel@host.hunter.org> <20131107074421.GL25335@redhat.com> Message-ID: <20131107083931.GB5103@hendrix.brq.redhat.com> On Thu, Nov 07, 2013 at 09:44:21AM +0200, Alexander Bokovoy wrote: > On Wed, 06 Nov 2013, Dean Hunter wrote: > > >After building a new VM and configuring the IPA 3.3.2 client, Gnome > >seems to only perform a local log-in until the system is rebooted. SSH > >works with IPA, but not Gnome. Is this correct? Is there anything less > >disruptive than a reboot that I can do? > Restart gdm.service? > I'm not sure how gdm handles PAM auth. I think the reason is actually nsswitch.conf, not PAM. Usually applications need to be restarted in order to notice changes to nsswitch.conf. That's also the reason why recent Fedora releases put "sss" to nsswitch.conf by default. From pviktori at redhat.com Thu Nov 7 11:36:59 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 07 Nov 2013 12:36:59 +0100 Subject: [Freeipa-users] External CA In-Reply-To: References: <527A47AE.9070607@redhat.com> Message-ID: <527B7B5B.9000200@redhat.com> On 11/07/2013 08:34 AM, William Leese wrote: > > [root at vagrant-centos-6 CA]# cat /root/server.pem > Certificate: > Data: > Version: 3 (0x2) > Serial Number: 2 (0x2) > Signature Algorithm: sha1WithRSAEncryption > Issuer: C=JP, ST=TK, L=TKK, O=MW, OU=ops, > CN=vagrant.localdomain/__emailAddress=t at t.com > > > > Validity > Not Before: Nov 6 05:12:09 2013 GMT > Not After : Nov 6 05:12:09 2014 GMT > Subject: O=MELTWATER.COM > , CN=Certificate > > Authority > [snip] > -----BEGIN CERTIFICATE----- > MIIDfDCCAmSgAwIBAgIBAjANBgkqhk__iG9w0BAQUFADB5MQswCQYDVQQGEwJK__UDEL > MAkGA1UECAwCVEsxDDAKBgNVBAcMA1__RLSzELMAkGA1UECgwCTVcxDDAKBgNV__BAsM > A29wczEcMBoGA1UEAwwTdmFncmFudC__5sb2NhbGRvbWFpbjEWMBQGCSqGSIb3__DQEJ > [snip] > > > Try removing everything before the -----BEGIN CERTIFICATE----- line > from the PEM. > > Well that was unexpected: removing the BEGIN Certificate / End lines now > makes the install proceed up until: > > The log file for this installation can be found in > /var/log/ipaserver-install.log > The PKCS#10 certificate is not signed by the external CA (unknown issuer > E=x at x.com ,CN=vagrant-centos-6,OU=JP,O=JP,L=JP,ST=JP,C=JP). Can you please post more (all) of /var/lig/ipaserver-install.log? We need to know where exactly the issue is occuring and what the traceback is. > Do I need to do anything to make my freshly created internal CA trusted > for the installation? I've tried the usual magic in /etc/pki/tls/certs, > but to no avail. No, --external_ca_file should have been enough. -- Petr? From abontempi at dbmsrl.com Thu Nov 7 12:39:21 2013 From: abontempi at dbmsrl.com (Andrea Bontempi) Date: Thu, 7 Nov 2013 13:39:21 +0100 (CET) Subject: [Freeipa-users] Installation issues with sub-ca. In-Reply-To: <527A74FC.5050501@redhat.com> References: <1008786015.35062.1383756329711.JavaMail.root@dbmsrl.com> <527A74FC.5050501@redhat.com> Message-ID: <1138098293.38547.1383827961817.JavaMail.root@dbmsrl.com> > -12195 is SSL_ERROR_UNKNOWN_CA_ALERT in NSS. > >I wonder if the root chain you gave to the IPA installer was complete. > >rob I work with PEM file format, in the sub-ca certificate there aren't chains (but isn't a problem if i use a self-generated CA). (Moreover, the script has all the chain, the root certificate and the FreeIPA's certificate, so it's strange.) I try to add the chain follow this rule: http://www.digicert.com/ssl-support/pem-ssl-creation.htm, but the script crash (does't seem to support this method) I fear it's a problem of my CA, but i have no idea what goes wrong. Thank you for all From rcritten at redhat.com Thu Nov 7 14:03:22 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 07 Nov 2013 09:03:22 -0500 Subject: [Freeipa-users] question about generating certificates In-Reply-To: <1383806008.3819.65.camel@coruscant.bashnl.ru> References: <1383725778.3819.15.camel@coruscant.bashnl.ru> <1383739262.3819.41.camel@coruscant.bashnl.ru> <20131106125201.GI25335@redhat.com> <1383799749.3819.48.camel@coruscant.bashnl.ru> <1383806008.3819.65.camel@coruscant.bashnl.ru> Message-ID: <527B9DAA.7010403@redhat.com> Arthur Faizullin wrote: > I have found what that means. It is again something with access rights. > Rob Crittenden says that it is better to generate > certificates at: > /etc/pki/tls/private/postgresql.key > /etc/pki/tls/certs/postgresql.crt > and if these files owner is postgres then postgresql is starting well, > but I do not know if certmonger will keep be tracking these file in case > of owner changed. It will be fine. certmonger runs as root. rob > > ? ??, 07/11/2013 ? 10:49 +0600, Arthur Faizullin ?????: >> ? ??, 06/11/2013 ? 14:52 +0200, Alexander Bokovoy ?????: >>> On Wed, 06 Nov 2013, Arthur Faizullin wrote: >>>> ????? ??????? ??????????? has give me advise that the >>>> problem may be in Selinux. >>>> so I has stoped tracking previous request by >>>> $ sudo ipa-getcert stop-tracking -i 20131106075356 >>>> >>>> and has generated new request >>>> # ipa-getcert request -f /var/lib/certmonger/requests/server.crt >>>> -k /var/lib/certmonger/requests/server.key -K >>>> postgresql/postgresql.example.com -N CN=postgresql.example.com -D >>>> postgresql.example.com >>>> >>>> that made desired files to appear at /var/lib/certmonger/requests/ >>>> that is okay! :) >>>> but! I want them in /var/lib/pgsql/9.3/data/ >>>> so what is the problem? why not just copy them at that directory? >>>> the problem is that when I list cert requests, I see this: >>>> Request ID '20131106113520': >>>> status: MONITORING >>>> stuck: no >>>> key pair storage: >>>> type=FILE,location='/var/lib/certmonger/requests/server.key' >>>> certificate: >>>> type=FILE,location='/var/lib/certmonger/requests/server.crt' >>>> CA: IPA >>>> issuer: CN=Certificate Authority,O=EXAMPLE.COM >>>> subject: CN=postgresql.example.com,O=EXAMPLE.COM >>>> expires: 2015-11-07 11:35:20 UTC >>>> eku: id-kp-serverAuth,id-kp-clientAuth >>>> pre-save command: >>>> post-save command: >>>> track: yes >>>> auto-renew: yes >>>> >>>> we can see that file location in that list is defined at request time. >>>> >>>> Shall I make Selinux to let certmonger to access /var/lib/pgsql ? or is >>>> there any other solution? >>> certmonger does run under certmonger_t SELinux type and system_r role. >>> It can already write to file contexts named certmonger_*_t and cert_t. For >>> storing certificates you would need to use cert_t file context. >>> >>> mkdir -p /var/lib/pgsql/9.3/data/certs >>> semanage fcontext -a -t cert_t '/var/lib/pgsql/9.3/data/certs(/.*)?' >>> restorecon -R -v /var/lib/pgsql/9.3/data/certs >>> >>> I would advise you against placing the files directly in >>> /var/lib/pgsql/9.3/data as opposed to the subdirectory. It is safer to >>> specify path to the certificate in pgsql configuration. >> >> I have tried it, but I still get this answer: >> # ipa-getcert request -f /var/lib/pgsql/9.3/data/certs/server.crt >> -k /var/lib/pgsql/9.3/data/certs/server.key -K >> postgresql/postgresql.example.com -N CN=postgresql.example.com -D >> postgresql.example.com >> The parent of location "/var/lib/pgsql/9.3/data/certs/server.crt" must >> be a valid directory. >> >> What does "valid directory" mean? >> >>> >>>> And I think that there mast be note at documentation about such >>>> situations with Selinux. >>> Yes. You can also install selinux-policy-devel package and read >>> certmonger_selinux (8) manpage. >>> >>> Can you open a ticket against FreeIPA documentation. >> >> Is bug opened by Dmitri Pal enough? >> https://bugzilla.redhat.com/show_bug.cgi?id=1027265 >>> >> >> >> _______________________________________________ >> 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 arthur at deus.pro Thu Nov 7 14:47:35 2013 From: arthur at deus.pro (Arthur) Date: Thu, 07 Nov 2013 20:47:35 +0600 Subject: [Freeipa-users] reboot required after ipa-client-install? In-Reply-To: <20131107083931.GB5103@hendrix.brq.redhat.com> References: <1383797622.19912.34.camel@host.hunter.org> <20131107074421.GL25335@redhat.com> <20131107083931.GB5103@hendrix.brq.redhat.com> Message-ID: <527BA807.5040601@deus.pro> I do not know, may be I am wrong somewhere, but I did not make any extra things with config files, just run ipa-client-install and everything seemed works fine. that worked for f17, f18, f19 with ipa-server on CentOS 6.3&6.4. Jakub Hrozek wrote: > On Thu, Nov 07, 2013 at 09:44:21AM +0200, Alexander Bokovoy wrote: >> On Wed, 06 Nov 2013, Dean Hunter wrote: >> >>> After building a new VM and configuring the IPA 3.3.2 client, Gnome >>> seems to only perform a local log-in until the system is rebooted. SSH >>> works with IPA, but not Gnome. Is this correct? Is there anything less >>> disruptive than a reboot that I can do? >> Restart gdm.service? >> I'm not sure how gdm handles PAM auth. > I think the reason is actually nsswitch.conf, not PAM. Usually > applications need to be restarted in order to notice changes to > nsswitch.conf. That's also the reason why recent Fedora releases put > "sss" to nsswitch.conf by default. > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From rcritten at redhat.com Thu Nov 7 14:52:58 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 07 Nov 2013 09:52:58 -0500 Subject: [Freeipa-users] Installation issues with sub-ca. In-Reply-To: <1138098293.38547.1383827961817.JavaMail.root@dbmsrl.com> References: <1008786015.35062.1383756329711.JavaMail.root@dbmsrl.com> <527A74FC.5050501@redhat.com> <1138098293.38547.1383827961817.JavaMail.root@dbmsrl.com> Message-ID: <527BA94A.9010400@redhat.com> Andrea Bontempi wrote: >> -12195 is SSL_ERROR_UNKNOWN_CA_ALERT in NSS. >> >> I wonder if the root chain you gave to the IPA installer was complete. >> >> rob > > I work with PEM file format, in the sub-ca certificate there aren't chains (but isn't a problem if i use a self-generated CA). > > (Moreover, the script has all the chain, the root certificate and the FreeIPA's certificate, so it's strange.) > > I try to add the chain follow this rule: http://www.digicert.com/ssl-support/pem-ssl-creation.htm, but the script crash (does't seem to support this method) > > I fear it's a problem of my CA, but i have no idea what goes wrong. Can you provide the logs from the failed install? /var/log/ipaserver-install.log for sure, we may need the debug log from the CA eventually too. rob From jhrozek at redhat.com Thu Nov 7 16:53:39 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 7 Nov 2013 17:53:39 +0100 Subject: [Freeipa-users] reboot required after ipa-client-install? In-Reply-To: <527BA807.5040601@deus.pro> References: <1383797622.19912.34.camel@host.hunter.org> <20131107074421.GL25335@redhat.com> <20131107083931.GB5103@hendrix.brq.redhat.com> <527BA807.5040601@deus.pro> Message-ID: <20131107165339.GB9381@hendrix.brq.redhat.com> On Thu, Nov 07, 2013 at 08:47:35PM +0600, Arthur wrote: > I do not know, may be I am wrong somewhere, but I did not make any > extra things with config files, just run ipa-client-install and > everything seemed works fine. ipa-client-install modifies /etc/nsswitch.conf and adds "sss" to the list of modules if not already there. > that worked for f17, f18, f19 with ipa-server on CentOS 6.3&6.4. I'm not sure about F-19 from the top of my head, sorry, but starting with F-20 at least you'll get sss configured right from the install time. > > Jakub Hrozek wrote: > >On Thu, Nov 07, 2013 at 09:44:21AM +0200, Alexander Bokovoy wrote: > >>On Wed, 06 Nov 2013, Dean Hunter wrote: > >> > >>>After building a new VM and configuring the IPA 3.3.2 client, Gnome > >>>seems to only perform a local log-in until the system is rebooted. SSH > >>>works with IPA, but not Gnome. Is this correct? Is there anything less > >>>disruptive than a reboot that I can do? > >>Restart gdm.service? > >>I'm not sure how gdm handles PAM auth. > >I think the reason is actually nsswitch.conf, not PAM. Usually > >applications need to be restarted in order to notice changes to > >nsswitch.conf. That's also the reason why recent Fedora releases put > >"sss" to nsswitch.conf by default. > > > >_______________________________________________ > >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 deanhunter at comcast.net Thu Nov 7 17:21:25 2013 From: deanhunter at comcast.net (Dean Hunter) Date: Thu, 07 Nov 2013 11:21:25 -0600 Subject: [Freeipa-users] reboot required after ipa-client-install? In-Reply-To: <20131107074421.GL25335@redhat.com> References: <1383797622.19912.34.camel@host.hunter.org> <20131107074421.GL25335@redhat.com> Message-ID: <1383844885.19912.43.camel@host.hunter.org> On Thu, 2013-11-07 at 09:44 +0200, Alexander Bokovoy wrote: > On Wed, 06 Nov 2013, Dean Hunter wrote: > > >After building a new VM and configuring the IPA 3.3.2 client, Gnome > >seems to only perform a local log-in until the system is rebooted. SSH > >works with IPA, but not Gnome. Is this correct? Is there anything less > >disruptive than a reboot that I can do? > Restart gdm.service? > I'm not sure how gdm handles PAM auth. I have tried: ipa-client-install ... systemctl restart gdm.service but the behavior remains the same. The Gnome log in screen accepts the user name, pauses about 25 seconds, then displays the log in screen again without any messages or indication of a problem. This is the same behavior I see when entering an incorrect local user name before configuring IPA. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Thu Nov 7 17:36:44 2013 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 07 Nov 2013 12:36:44 -0500 Subject: [Freeipa-users] reboot required after ipa-client-install? In-Reply-To: <1383844885.19912.43.camel@host.hunter.org> References: <1383797622.19912.34.camel@host.hunter.org> <20131107074421.GL25335@redhat.com> <1383844885.19912.43.camel@host.hunter.org> Message-ID: <527BCFAC.4080003@redhat.com> On 11/07/2013 12:21 PM, Dean Hunter wrote: > On Thu, 2013-11-07 at 09:44 +0200, Alexander Bokovoy wrote: >> On Wed, 06 Nov 2013, Dean Hunter wrote: >> >> >After building a new VM and configuring the IPA 3.3.2 client, Gnome >> >seems to only perform a local log-in until the system is rebooted. SSH >> >works with IPA, but not Gnome. Is this correct? Is there anything less >> >disruptive than a reboot that I can do? > >> Restart gdm.service? >> I'm not sure how gdm handles PAM auth. > > I have tried: > > ipa-client-install ... > systemctl restart gdm.service > > but the behavior remains the same. The Gnome log in screen accepts the > user name, pauses about 25 seconds, then displays the log in screen > again without any messages or indication of a problem. This is the > same behavior I see when entering an incorrect local user name before > configuring IPA. > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users Can it be a DIR cache issue and the fact that the directory can't is not created at proper time? Do you see any AVCs? -- 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 deanhunter at comcast.net Thu Nov 7 17:59:48 2013 From: deanhunter at comcast.net (Dean Hunter) Date: Thu, 07 Nov 2013 11:59:48 -0600 Subject: [Freeipa-users] reboot required after ipa-client-install? In-Reply-To: <527BCFAC.4080003@redhat.com> References: <1383797622.19912.34.camel@host.hunter.org> <20131107074421.GL25335@redhat.com> <1383844885.19912.43.camel@host.hunter.org> <527BCFAC.4080003@redhat.com> Message-ID: <1383847188.19912.44.camel@host.hunter.org> On Thu, 2013-11-07 at 12:36 -0500, Dmitri Pal wrote: > On 11/07/2013 12:21 PM, Dean Hunter wrote: > > > On Thu, 2013-11-07 at 09:44 +0200, Alexander Bokovoy wrote: > > > > > On Wed, 06 Nov 2013, Dean Hunter wrote: > > > > > > >After building a new VM and configuring the IPA 3.3.2 client, Gnome > > > >seems to only perform a local log-in until the system is rebooted. SSH > > > >works with IPA, but not Gnome. Is this correct? Is there anything less > > > >disruptive than a reboot that I can do? > > > > > > > > > Restart gdm.service? > > > I'm not sure how gdm handles PAM auth. > > > > > > I have tried: > > > > ipa-client-install ... > > systemctl restart gdm.service > > > > but the behavior remains the same. The Gnome log in screen accepts > > the user name, pauses about 25 seconds, then displays the log in > > screen again without any messages or indication of a problem. This > > is the same behavior I see when entering an incorrect local user > > name before configuring IPA. > > > > > > > > > > _______________________________________________ > > Freeipa-users mailing list > > Freeipa-users at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-users > > Can it be a DIR cache issue and the fact that the directory can't is > not created at proper time? Which directory, please? > Do you see any AVCs? > > > -- > 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 jonathan.underwood at gmail.com Thu Nov 7 18:49:09 2013 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Thu, 7 Nov 2013 18:49:09 +0000 Subject: [Freeipa-users] ipa cli AttributeError: KerbTransport instance has no attribute '_conn' Message-ID: Hi, I have just done a fresh server install of ipa on a Scientific Linux 6.4 machine, and I am finding the command line utilities are failing with: # ipa ping ipa: ERROR: non-public: AttributeError: KerbTransport instance has no attribute '_conn' Traceback (most recent call last): File "/usr/lib/python2.6/site-packages/ipalib/backend.py", line 129, in execute result = self.Command[_name](*args, **options) File "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line 435, in __call__ ret = self.run(*args, **options) File "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line 748, in run return self.forward(*args, **options) File "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line 769, in forward return self.Backend.xmlclient.forward(self.name, *args, **kw) File "/usr/lib/python2.6/site-packages/ipalib/rpc.py", line 728, in forward response = command(*xml_wrap(params)) File "/usr/lib64/python2.6/xmlrpclib.py", line 1199, in __call__ return self.__send(self.__name, args) File "/usr/lib64/python2.6/xmlrpclib.py", line 1489, in __request verbose=self.__verbose File "/usr/lib/python2.6/site-packages/ipalib/rpc.py", line 475, in request self.close() File "/usr/lib/python2.6/site-packages/ipalib/rpc.py", line 442, in close self._conn.close() AttributeError: KerbTransport instance has no attribute '_conn' ipa: ERROR: an internal error has occurred Other ipa commands fail the same way. I have no problems searching the LDAP directory (ldapsearch -Y GSSAPI works fine), "getent passwd admin" returns sensible information. So, I am a bitstumped as to how to debug this further. Any suggestions? Package versions: Installed Packages ipa-admintools.x86_64 3.0.0-25.el6 @sl ipa-client.x86_64 3.0.0-25.el6 @sl ipa-pki-ca-theme.noarch 9.0.3-7.el6 @sl ipa-pki-common-theme.noarch 9.0.3-7.el6 @sl ipa-python.x86_64 3.0.0-25.el6 @anaconda-ScientificLinux-201303180938.x86_64/6.1 ipa-server.x86_64 3.0.0-25.el6 @sl ipa-server-selinux.x86_64 3.0.0-25.el6 @sl Thanks in advance, Jonathan. From dpal at redhat.com Thu Nov 7 22:41:31 2013 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 07 Nov 2013 17:41:31 -0500 Subject: [Freeipa-users] reboot required after ipa-client-install? In-Reply-To: <1383847188.19912.44.camel@host.hunter.org> References: <1383797622.19912.34.camel@host.hunter.org> <20131107074421.GL25335@redhat.com> <1383844885.19912.43.camel@host.hunter.org> <527BCFAC.4080003@redhat.com> <1383847188.19912.44.camel@host.hunter.org> Message-ID: <527C171B.8010209@redhat.com> On 11/07/2013 12:59 PM, Dean Hunter wrote: > On Thu, 2013-11-07 at 12:36 -0500, Dmitri Pal wrote: >> On 11/07/2013 12:21 PM, Dean Hunter wrote: >>> On Thu, 2013-11-07 at 09:44 +0200, Alexander Bokovoy wrote: >>>> On Wed, 06 Nov 2013, Dean Hunter wrote: >>>> >>>> >After building a new VM and configuring the IPA 3.3.2 client, Gnome >>>> >seems to only perform a local log-in until the system is rebooted. SSH >>>> >works with IPA, but not Gnome. Is this correct? Is there anything less >>>> >disruptive than a reboot that I can do? >>> >>>> Restart gdm.service? >>>> I'm not sure how gdm handles PAM auth. >>> >>> I have tried: >>> >>> ipa-client-install ... >>> systemctl restart gdm.service >>> >>> but the behavior remains the same. The Gnome log in screen accepts >>> the user name, pauses about 25 seconds, then displays the log in >>> screen again without any messages or indication of a problem. This >>> is the same behavior I see when entering an incorrect local user >>> name before configuring IPA. >>> >>> >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >> Can it be a DIR cache issue and the fact that the directory can't is >> not created at proper time? > > Which directory, please? If you are hitting the DIR cache issue (which I am not sure is the case this is why I asked about AVCs) then the directory we are talking about is /var/run/usr/ This directory should be created by kerberos library when it tries to authenticate a user. But it might not be able to since a parent directory /var/run/usr might not be created yet. This is one of the reasons why we decided not to continue the path of DIR cache but switched to using Kernel based ccache. > >> Do you see any AVCs? Question still stands. >> >> -- >> 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 Thu Nov 7 22:43:21 2013 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 07 Nov 2013 17:43:21 -0500 Subject: [Freeipa-users] ipa cli AttributeError: KerbTransport instance has no attribute '_conn' In-Reply-To: References: Message-ID: <527C1789.1030302@redhat.com> On 11/07/2013 01:49 PM, Jonathan Underwood wrote: > Hi, > > I have just done a fresh server install of ipa on a Scientific Linux > 6.4 machine, and I am finding the command line utilities are failing > with: > > # ipa ping > ipa: ERROR: non-public: AttributeError: KerbTransport instance has no > attribute '_conn' > Traceback (most recent call last): > File "/usr/lib/python2.6/site-packages/ipalib/backend.py", line 129, > in execute > result = self.Command[_name](*args, **options) > File "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line > 435, in __call__ > ret = self.run(*args, **options) > File "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line 748, in run > return self.forward(*args, **options) > File "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line > 769, in forward > return self.Backend.xmlclient.forward(self.name, *args, **kw) > File "/usr/lib/python2.6/site-packages/ipalib/rpc.py", line 728, in forward > response = command(*xml_wrap(params)) > File "/usr/lib64/python2.6/xmlrpclib.py", line 1199, in __call__ > return self.__send(self.__name, args) > File "/usr/lib64/python2.6/xmlrpclib.py", line 1489, in __request > verbose=self.__verbose > File "/usr/lib/python2.6/site-packages/ipalib/rpc.py", line 475, in request > self.close() > File "/usr/lib/python2.6/site-packages/ipalib/rpc.py", line 442, in close > self._conn.close() > AttributeError: KerbTransport instance has no attribute '_conn' > ipa: ERROR: an internal error has occurred > > > Other ipa commands fail the same way. > > I have no problems searching the LDAP directory (ldapsearch -Y GSSAPI > works fine), "getent passwd admin" returns sensible information. So, I > am a bitstumped as to how to debug this further. Any suggestions? > > Package versions: > > Installed Packages > ipa-admintools.x86_64 3.0.0-25.el6 > @sl > ipa-client.x86_64 3.0.0-25.el6 > @sl > ipa-pki-ca-theme.noarch 9.0.3-7.el6 > @sl > ipa-pki-common-theme.noarch 9.0.3-7.el6 > @sl > ipa-python.x86_64 3.0.0-25.el6 > @anaconda-ScientificLinux-201303180938.x86_64/6.1 > ipa-server.x86_64 3.0.0-25.el6 > @sl > ipa-server-selinux.x86_64 3.0.0-25.el6 > @sl > > > Thanks in advance, > Jonathan. > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users What about Kerberos package? -- 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 Nov 7 22:45:16 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 07 Nov 2013 17:45:16 -0500 Subject: [Freeipa-users] ipa cli AttributeError: KerbTransport instance has no attribute '_conn' In-Reply-To: References: Message-ID: <527C17FC.8000301@redhat.com> Jonathan Underwood wrote: > Hi, > > I have just done a fresh server install of ipa on a Scientific Linux > 6.4 machine, and I am finding the command line utilities are failing > with: > > # ipa ping > ipa: ERROR: non-public: AttributeError: KerbTransport instance has no > attribute '_conn' > Traceback (most recent call last): > File "/usr/lib/python2.6/site-packages/ipalib/backend.py", line 129, > in execute > result = self.Command[_name](*args, **options) > File "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line > 435, in __call__ > ret = self.run(*args, **options) > File "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line 748, in run > return self.forward(*args, **options) > File "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line > 769, in forward > return self.Backend.xmlclient.forward(self.name, *args, **kw) > File "/usr/lib/python2.6/site-packages/ipalib/rpc.py", line 728, in forward > response = command(*xml_wrap(params)) > File "/usr/lib64/python2.6/xmlrpclib.py", line 1199, in __call__ > return self.__send(self.__name, args) > File "/usr/lib64/python2.6/xmlrpclib.py", line 1489, in __request > verbose=self.__verbose > File "/usr/lib/python2.6/site-packages/ipalib/rpc.py", line 475, in request > self.close() > File "/usr/lib/python2.6/site-packages/ipalib/rpc.py", line 442, in close > self._conn.close() > AttributeError: KerbTransport instance has no attribute '_conn' > ipa: ERROR: an internal error has occurred > > > Other ipa commands fail the same way. > > I have no problems searching the LDAP directory (ldapsearch -Y GSSAPI > works fine), "getent passwd admin" returns sensible information. So, I > am a bitstumped as to how to debug this further. Any suggestions? This is it trying to close a connection that was never made. Can you run ipa -vv ping? rob From deanhunter at comcast.net Thu Nov 7 23:20:09 2013 From: deanhunter at comcast.net (Dean Hunter) Date: Thu, 07 Nov 2013 17:20:09 -0600 Subject: [Freeipa-users] reboot required after ipa-client-install? In-Reply-To: <527C171B.8010209@redhat.com> References: <1383797622.19912.34.camel@host.hunter.org> <20131107074421.GL25335@redhat.com> <1383844885.19912.43.camel@host.hunter.org> <527BCFAC.4080003@redhat.com> <1383847188.19912.44.camel@host.hunter.org> <527C171B.8010209@redhat.com> Message-ID: <1383866409.2467.6.camel@host.hunter.org> On Thu, 2013-11-07 at 17:41 -0500, Dmitri Pal wrote: > On 11/07/2013 12:59 PM, Dean Hunter wrote: > > > On Thu, 2013-11-07 at 12:36 -0500, Dmitri Pal wrote: > > > > > On 11/07/2013 12:21 PM, Dean Hunter wrote: > > > > > > > On Thu, 2013-11-07 at 09:44 +0200, Alexander Bokovoy wrote: > > > > > > > > > On Wed, 06 Nov 2013, Dean Hunter wrote: > > > > > > > > > > >After building a new VM and configuring the IPA 3.3.2 client, Gnome > > > > > >seems to only perform a local log-in until the system is rebooted. SSH > > > > > >works with IPA, but not Gnome. Is this correct? Is there anything less > > > > > >disruptive than a reboot that I can do? > > > > > > > > > > > > > > > > > Restart gdm.service? > > > > > I'm not sure how gdm handles PAM auth. > > > > > > > > > > > > I have tried: > > > > > > > > ipa-client-install ... > > > > systemctl restart gdm.service > > > > > > > > but the behavior remains the same. The Gnome log in screen > > > > accepts the user name, pauses about 25 seconds, then displays > > > > the log in screen again without any messages or indication of a > > > > problem. This is the same behavior I see when entering an > > > > incorrect local user name before configuring IPA. > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Freeipa-users mailing list > > > > Freeipa-users at redhat.com > > > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > > Can it be a DIR cache issue and the fact that the directory can't > > > is not created at proper time? > > > > > > Which directory, please? > > > If you are hitting the DIR cache issue (which I am not sure is the > case this is why I asked about AVCs) then the directory we are talking > about is /var/run/usr/ > This directory should be created by kerberos library when it tries to > authenticate a user. But it might not be able to since a parent > directory /var/run/usr might not be created yet. This is one of the > reasons why we decided not to continue the path of DIR cache but > switched to using Kernel based ccache. > > > > > > > > > > Do you see any AVCs? > > > Question still stands. I see no AVCs: [root at ipa ~]# ausearch --message AVC [root at ipa ~]# I did find this in the man page for nsswitch.conf: FILES A service named SERVICE is implemented by a shared object library named libnss_SERVICE.so.X that resides in /lib. /etc/nsswitch.conf NSS configuration file. /lib/libnss_compat.so.X implements "compat" source. /lib/libnss_db.so.X implements "db" source. /lib/libnss_dns.so.X implements "dns" source. /lib/libnss_files.so.X implements "files" source. /lib/libnss_hesiod.so.X implements "hesiod" source. /lib/libnss_nis.so.X implements "nis" source. /lib/libnss_nisplus.so.X implements "nisplus" source. NOTES Within each process that uses nsswitch.conf, the entire file is read only once. If the file is later changed, the process will continue using the old configuration. Is this why the default configuration of nsswitch.conf is changing in Fedora 20, as noted on of the preceeding e-mails? -------------- next part -------------- An HTML attachment was scrubbed... URL: From william.leese at meltwater.com Fri Nov 8 00:55:40 2013 From: william.leese at meltwater.com (William Leese) Date: Fri, 8 Nov 2013 09:55:40 +0900 Subject: [Freeipa-users] External CA In-Reply-To: <527B7B5B.9000200@redhat.com> References: <527A47AE.9070607@redhat.com> <527B7B5B.9000200@redhat.com> Message-ID: I was able to solve this by recreating my test CA. I believe the problem was with non-matching Organisation between the CSR and CA - but I dont have the knowledge to know if this is really required. Anyhow, things work, despite not having removed the "-----BEGIN CERTIFICATE-----" lines this time around. Thanks for the help and sorry for wasting your time! -- William Leese Production Engineer, Operations, Asia Pacific Meltwater Group m: +81 80 4946 0329 skype: william.leese1 w: meltwater.com This email and any attachment(s) is intended for and confidential to the addressee. If you are neither the addressee nor an authorized recipient for the addressee, please notify us of receipt, delete this message from your system and do not use, copy or disseminate the information in, or attached to it, in any way. Our messages are checked for viruses but please note that we do not accept liability for any viruses which may be transmitted in or with this message. On Thu, Nov 7, 2013 at 8:36 PM, Petr Viktorin wrote: > On 11/07/2013 08:34 AM, William Leese wrote: > >> >> [root at vagrant-centos-6 CA]# cat /root/server.pem >> Certificate: >> Data: >> Version: 3 (0x2) >> Serial Number: 2 (0x2) >> Signature Algorithm: sha1WithRSAEncryption >> Issuer: C=JP, ST=TK, L=TKK, O=MW, OU=ops, >> CN=vagrant.localdomain/__emailAddress=t at t.com >> > >> >> >> Validity >> Not Before: Nov 6 05:12:09 2013 GMT >> Not After : Nov 6 05:12:09 2014 GMT >> Subject: O=MELTWATER.COM >> , CN=Certificate >> >> Authority >> [snip] >> -----BEGIN CERTIFICATE----- >> MIIDfDCCAmSgAwIBAgIBAjANBgkqhk__iG9w0BAQUFADB5MQswCQYDVQQGEwJK >> __UDEL >> MAkGA1UECAwCVEsxDDAKBgNVBAcMA1__RLSzELMAkGA1UECgwCTVcxDDAKBgNV >> __BAsM >> A29wczEcMBoGA1UEAwwTdmFncmFudC__5sb2NhbGRvbWFpbjEWMBQGCSqGSIb3 >> __DQEJ >> >> [snip] >> >> >> Try removing everything before the -----BEGIN CERTIFICATE----- line >> from the PEM. >> >> Well that was unexpected: removing the BEGIN Certificate / End lines now >> makes the install proceed up until: >> >> The log file for this installation can be found in >> /var/log/ipaserver-install.log >> The PKCS#10 certificate is not signed by the external CA (unknown issuer >> E=x at x.com ,CN=vagrant-centos-6,OU=JP,O=JP,L=JP,ST= >> JP,C=JP). >> > > Can you please post more (all) of /var/lig/ipaserver-install.log? We need > to know where exactly the issue is occuring and what the traceback is. > > > Do I need to do anything to make my freshly created internal CA trusted >> for the installation? I've tried the usual magic in /etc/pki/tls/certs, >> but to no avail. >> > > No, --external_ca_file should have been enough. > > -- > Petr? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Fri Nov 8 03:17:44 2013 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 07 Nov 2013 22:17:44 -0500 Subject: [Freeipa-users] reboot required after ipa-client-install? In-Reply-To: <1383866409.2467.6.camel@host.hunter.org> References: <1383797622.19912.34.camel@host.hunter.org> <20131107074421.GL25335@redhat.com> <1383844885.19912.43.camel@host.hunter.org> <527BCFAC.4080003@redhat.com> <1383847188.19912.44.camel@host.hunter.org> <527C171B.8010209@redhat.com> <1383866409.2467.6.camel@host.hunter.org> Message-ID: <527C57D8.7090202@redhat.com> On 11/07/2013 06:20 PM, Dean Hunter wrote: > On Thu, 2013-11-07 at 17:41 -0500, Dmitri Pal wrote: >> On 11/07/2013 12:59 PM, Dean Hunter wrote: >>> On Thu, 2013-11-07 at 12:36 -0500, Dmitri Pal wrote: >>>> On 11/07/2013 12:21 PM, Dean Hunter wrote: >>>>> On Thu, 2013-11-07 at 09:44 +0200, Alexander Bokovoy wrote: >>>>>> On Wed, 06 Nov 2013, Dean Hunter wrote: >>>>>> >>>>>> >After building a new VM and configuring the IPA 3.3.2 client, Gnome >>>>>> >seems to only perform a local log-in until the system is rebooted. SSH >>>>>> >works with IPA, but not Gnome. Is this correct? Is there anything less >>>>>> >disruptive than a reboot that I can do? >>>>> >>>>>> Restart gdm.service? >>>>>> I'm not sure how gdm handles PAM auth. >>>>> >>>>> I have tried: >>>>> >>>>> ipa-client-install ... >>>>> systemctl restart gdm.service >>>>> >>>>> but the behavior remains the same. The Gnome log in screen accepts >>>>> the user name, pauses about 25 seconds, then displays the log in >>>>> screen again without any messages or indication of a problem. This >>>>> is the same behavior I see when entering an incorrect local user >>>>> name before configuring IPA. >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Freeipa-users mailing list >>>>> Freeipa-users at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>> Can it be a DIR cache issue and the fact that the directory can't >>>> is not created at proper time? >>> >>> Which directory, please? >> >> If you are hitting the DIR cache issue (which I am not sure is the >> case this is why I asked about AVCs) then the directory we are >> talking about is /var/run/usr/ >> This directory should be created by kerberos library when it tries to >> authenticate a user. But it might not be able to since a parent >> directory /var/run/usr might not be created yet. This is one of the >> reasons why we decided not to continue the path of DIR cache but >> switched to using Kernel based ccache. >> >> >>> >>>> Do you see any AVCs? >> >> Question still stands. > > I see no AVCs: > > [root at ipa ~]# ausearch --message AVC > > [root at ipa ~]# > > I did find this in the man page for nsswitch.conf: > > FILES > A service named SERVICE is implemented by a shared object > library named > libnss_SERVICE.so.X that resides in /lib. > > /etc/nsswitch.conf NSS configuration file. > /lib/libnss_compat.so.X implements "compat" source. > /lib/libnss_db.so.X implements "db" source. > /lib/libnss_dns.so.X implements "dns" source. > /lib/libnss_files.so.X implements "files" source. > /lib/libnss_hesiod.so.X implements "hesiod" source. > /lib/libnss_nis.so.X implements "nis" source. > /lib/libnss_nisplus.so.X implements "nisplus" source. > > NOTES > Within each process that uses nsswitch.conf, the entire > file is read > only once. If the file is later changed, the process > will continue > using the old configuration. > > > Is this why the default configuration of nsswitch.conf is changing in > Fedora 20, as noted on of the preceeding e-mails? > Yes I think SSS is now included by default. But if man page does not list it it is probably a bug in the man page. -- 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 mkosek at redhat.com Fri Nov 8 08:01:00 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 08 Nov 2013 09:01:00 +0100 Subject: [Freeipa-users] External CA In-Reply-To: References: <527A47AE.9070607@redhat.com> <527B7B5B.9000200@redhat.com> Message-ID: <527C9A3C.9000008@redhat.com> Thanks for heads up. You mean by the difference between "O=MW" and "O=MELTWATER.COM"? Petr, is this possible? Can it be validated in the the installer if this is the root cause? Martin On 11/08/2013 01:55 AM, William Leese wrote: > I was able to solve this by recreating my test CA. I believe the problem > was with non-matching Organisation between the CSR and CA - but I dont have > the knowledge to know if this is really required. > > Anyhow, things work, despite not having removed the "-----BEGIN > CERTIFICATE-----" lines this time around. > > Thanks for the help and sorry for wasting your time! > > > -- > William Leese > Production Engineer, > Operations, Asia Pacific > Meltwater Group > m: +81 80 4946 0329 > skype: william.leese1 > w: meltwater.com > > This email and any attachment(s) is intended for and confidential to the > addressee. If you are neither the addressee nor an authorized recipient for > the addressee, please notify us of receipt, delete this message from your > system and do not use, copy or disseminate the information in, or attached > to it, in any way. Our messages are checked for viruses but please note > that we do not accept liability for any viruses which may be transmitted in > or with this message. > > > > On Thu, Nov 7, 2013 at 8:36 PM, Petr Viktorin wrote: > >> On 11/07/2013 08:34 AM, William Leese wrote: >> >>> >>> [root at vagrant-centos-6 CA]# cat /root/server.pem >>> Certificate: >>> Data: >>> Version: 3 (0x2) >>> Serial Number: 2 (0x2) >>> Signature Algorithm: sha1WithRSAEncryption >>> Issuer: C=JP, ST=TK, L=TKK, O=MW, OU=ops, >>> CN=vagrant.localdomain/__emailAddress=t at t.com >>> > >>> >>> >>> Validity >>> Not Before: Nov 6 05:12:09 2013 GMT >>> Not After : Nov 6 05:12:09 2014 GMT >>> Subject: O=MELTWATER.COM >>> , CN=Certificate >>> >>> Authority >>> [snip] >>> -----BEGIN CERTIFICATE----- >>> MIIDfDCCAmSgAwIBAgIBAjANBgkqhk__iG9w0BAQUFADB5MQswCQYDVQQGEwJK >>> __UDEL >>> MAkGA1UECAwCVEsxDDAKBgNVBAcMA1__RLSzELMAkGA1UECgwCTVcxDDAKBgNV >>> __BAsM >>> A29wczEcMBoGA1UEAwwTdmFncmFudC__5sb2NhbGRvbWFpbjEWMBQGCSqGSIb3 >>> __DQEJ >>> >>> [snip] >>> >>> >>> Try removing everything before the -----BEGIN CERTIFICATE----- line >>> from the PEM. >>> >>> Well that was unexpected: removing the BEGIN Certificate / End lines now >>> makes the install proceed up until: >>> >>> The log file for this installation can be found in >>> /var/log/ipaserver-install.log >>> The PKCS#10 certificate is not signed by the external CA (unknown issuer >>> E=x at x.com ,CN=vagrant-centos-6,OU=JP,O=JP,L=JP,ST= >>> JP,C=JP). >>> >> >> Can you please post more (all) of /var/lig/ipaserver-install.log? We need >> to know where exactly the issue is occuring and what the traceback is. >> >> >> Do I need to do anything to make my freshly created internal CA trusted >>> for the installation? I've tried the usual magic in /etc/pki/tls/certs, >>> but to no avail. >>> >> >> No, --external_ca_file should have been enough. >> >> -- >> Petr? >> > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > From william.leese at meltwater.com Fri Nov 8 08:12:23 2013 From: william.leese at meltwater.com (William Leese) Date: Fri, 8 Nov 2013 17:12:23 +0900 Subject: [Freeipa-users] External CA In-Reply-To: <527C9A3C.9000008@redhat.com> References: <527A47AE.9070607@redhat.com> <527B7B5B.9000200@redhat.com> <527C9A3C.9000008@redhat.com> Message-ID: > You mean by the difference between "O=MW" and "O=MELTWATER.COM"? Yes, but again I don't know for sure. I wasn't very diligent setting up my test CA. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Fri Nov 8 09:46:02 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 8 Nov 2013 10:46:02 +0100 Subject: [Freeipa-users] reboot required after ipa-client-install? In-Reply-To: <527C57D8.7090202@redhat.com> References: <1383797622.19912.34.camel@host.hunter.org> <20131107074421.GL25335@redhat.com> <1383844885.19912.43.camel@host.hunter.org> <527BCFAC.4080003@redhat.com> <1383847188.19912.44.camel@host.hunter.org> <527C171B.8010209@redhat.com> <1383866409.2467.6.camel@host.hunter.org> <527C57D8.7090202@redhat.com> Message-ID: <20131108094602.GC4481@hendrix.brq.redhat.com> On Thu, Nov 07, 2013 at 10:17:44PM -0500, Dmitri Pal wrote: > On 11/07/2013 06:20 PM, Dean Hunter wrote: > > On Thu, 2013-11-07 at 17:41 -0500, Dmitri Pal wrote: > >> On 11/07/2013 12:59 PM, Dean Hunter wrote: > >>> On Thu, 2013-11-07 at 12:36 -0500, Dmitri Pal wrote: > >>>> On 11/07/2013 12:21 PM, Dean Hunter wrote: > >>>>> On Thu, 2013-11-07 at 09:44 +0200, Alexander Bokovoy wrote: > >>>>>> On Wed, 06 Nov 2013, Dean Hunter wrote: > >>>>>> > >>>>>> >After building a new VM and configuring the IPA 3.3.2 client, Gnome > >>>>>> >seems to only perform a local log-in until the system is rebooted. SSH > >>>>>> >works with IPA, but not Gnome. Is this correct? Is there anything less > >>>>>> >disruptive than a reboot that I can do? > >>>>> > >>>>>> Restart gdm.service? > >>>>>> I'm not sure how gdm handles PAM auth. > >>>>> > >>>>> I have tried: > >>>>> > >>>>> ipa-client-install ... > >>>>> systemctl restart gdm.service > >>>>> > >>>>> but the behavior remains the same. The Gnome log in screen accepts > >>>>> the user name, pauses about 25 seconds, then displays the log in > >>>>> screen again without any messages or indication of a problem. This > >>>>> is the same behavior I see when entering an incorrect local user > >>>>> name before configuring IPA. > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> Freeipa-users mailing list > >>>>> Freeipa-users at redhat.com > >>>>> https://www.redhat.com/mailman/listinfo/freeipa-users > >>>> Can it be a DIR cache issue and the fact that the directory can't > >>>> is not created at proper time? > >>> > >>> Which directory, please? > >> > >> If you are hitting the DIR cache issue (which I am not sure is the > >> case this is why I asked about AVCs) then the directory we are > >> talking about is /var/run/usr/ > >> This directory should be created by kerberos library when it tries to > >> authenticate a user. But it might not be able to since a parent > >> directory /var/run/usr might not be created yet. This is one of the > >> reasons why we decided not to continue the path of DIR cache but > >> switched to using Kernel based ccache. > >> > >> > >>> > >>>> Do you see any AVCs? > >> > >> Question still stands. > > > > I see no AVCs: > > > > [root at ipa ~]# ausearch --message AVC > > > > [root at ipa ~]# > > > > I did find this in the man page for nsswitch.conf: > > > > FILES > > A service named SERVICE is implemented by a shared object > > library named > > libnss_SERVICE.so.X that resides in /lib. > > > > /etc/nsswitch.conf NSS configuration file. > > /lib/libnss_compat.so.X implements "compat" source. > > /lib/libnss_db.so.X implements "db" source. > > /lib/libnss_dns.so.X implements "dns" source. > > /lib/libnss_files.so.X implements "files" source. > > /lib/libnss_hesiod.so.X implements "hesiod" source. > > /lib/libnss_nis.so.X implements "nis" source. > > /lib/libnss_nisplus.so.X implements "nisplus" source. > > > > NOTES > > Within each process that uses nsswitch.conf, the entire > > file is read > > only once. If the file is later changed, the process > > will continue > > using the old configuration. > > > > > > Is this why the default configuration of nsswitch.conf is changing in > > Fedora 20, as noted on of the preceeding e-mails? > > > > > Yes I think SSS is now included by default. Yes, starting with F-20. > But if man page does not > list it it is probably a bug in the man page. I think the man page only lists modules that are shipped with the glibc RPM, not any 3rd party modules like nss_ldap or nss_sss. From pviktori at redhat.com Fri Nov 8 09:56:27 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 08 Nov 2013 10:56:27 +0100 Subject: [Freeipa-users] External CA In-Reply-To: <527C9A3C.9000008@redhat.com> References: <527A47AE.9070607@redhat.com> <527B7B5B.9000200@redhat.com> <527C9A3C.9000008@redhat.com> Message-ID: <527CB54B.1080808@redhat.com> On 11/08/2013 09:01 AM, Martin Kosek wrote: > Thanks for heads up. You mean by the difference between "O=MW" and > "O=MELTWATER.COM"? > > Petr, is this possible? Can it be validated in the the installer if this is the > root cause? It is possible. It's hard to tell without the logs; looks like the failure was inside Dogtag. There may be more issues; for instance I don't think we considered PEM files with extra data before the BEGIN CERTIFICATE. I filed a ticket to investigate: https://fedorahosted.org/freeipa/ticket/4019 > On 11/08/2013 01:55 AM, William Leese wrote: >> I was able to solve this by recreating my test CA. I believe the problem >> was with non-matching Organisation between the CSR and CA - but I dont have >> the knowledge to know if this is really required. >> >> Anyhow, things work, despite not having removed the "-----BEGIN >> CERTIFICATE-----" lines this time around. >> >> Thanks for the help and sorry for wasting your time! >> -- Petr? From jonathan.underwood at gmail.com Fri Nov 8 12:48:43 2013 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Fri, 8 Nov 2013 12:48:43 +0000 Subject: [Freeipa-users] ipa cli AttributeError: KerbTransport instance has no attribute '_conn' In-Reply-To: <527C1789.1030302@redhat.com> References: <527C1789.1030302@redhat.com> Message-ID: On 7 November 2013 22:43, Dmitri Pal wrote: > What about Kerberos package? # rpm -qa | grep krb krb5-server-1.10.3-10.el6_4.3.x86_64 krb5-libs-1.10.3-10.el6_4.3.x86_64 krb5-workstation-1.10.3-10.el6_4.3.x86_64 pam_krb5-2.3.11-9.el6.x86_64 python-krbV-1.0.90-3.el6.x86_64 From abontempi at dbmsrl.com Fri Nov 8 12:58:27 2013 From: abontempi at dbmsrl.com (Andrea Bontempi) Date: Fri, 8 Nov 2013 13:58:27 +0100 (CET) Subject: [Freeipa-users] FreeIPA 3.3.* bug with external-ca? In-Reply-To: <1985222444.42978.1383915071394.JavaMail.root@dbmsrl.com> Message-ID: <1731723855.43033.1383915507386.JavaMail.root@dbmsrl.com> Hi, i'm trying to install FreeIPA with external CA (again) Now i use FreeIPA 3.3.* and i found a strange error on "[17/22]: requesting RA certificate from CA": >2013-11-08T11:07:38Z DEBUG File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 622, in run_script > return_value = main_function() > > File "/usr/sbin/ipa-server-install", line 1096, in main > subject_base=options.subject) > > File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 478, in configure_instance > self.start_creation(runtime=210) > > File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 364, in start_creation > method() > > File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 1089, in __request_ra_certificate > self.requestId = item_node[0].childNodes[0].data > >2013-11-08T11:07:38Z DEBUG The ipa-server-install command failed, exception: IndexError: list index out of range So, i open /usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py on the line 1089: > # Send the request to the CA > conn = httplib.HTTPConnection( > self.fqdn, self.dogtag_constants.UNSECURE_PORT) > params = urllib.urlencode({'profileId': 'caServerCert', > 'cert_request_type': 'pkcs10', > 'requestor_name': 'IPA Installer', > 'cert_request': csr, > 'xmlOutput': 'true'}) > headers = {"Content-type": "application/x-www-form-urlencoded", > "Accept": "text/plain"} > > conn.request("POST", "/ca/ee/ca/profileSubmit", params, headers) > res = conn.getresponse() > if res.status == 200: > data = res.read() > conn.close() > doc = xml.dom.minidom.parseString(data) > item_node = doc.getElementsByTagName("RequestId") > self.requestId = item_node[0].childNodes[0].data <-- exception: IndexError: list index out of range > doc.unlink() > self.requestId = self.requestId.strip() > if self.requestId is None: > raise RuntimeError("Unable to determine RA certificate requestId") I read the value of "data": > > > 1 > Profile caServerCert Not Found > Can someone help me? Thank you From jonathan.underwood at gmail.com Fri Nov 8 13:17:21 2013 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Fri, 8 Nov 2013 13:17:21 +0000 Subject: [Freeipa-users] ipa cli AttributeError: KerbTransport instance has no attribute '_conn' In-Reply-To: References: <527C17FC.8000301@redhat.com> Message-ID: On 8 November 2013 12:50, Jonathan Underwood wrote: > On 7 November 2013 22:45, Rob Crittenden wrote: >> This is it trying to close a connection that was never made. >> >> Can you run ipa -vv ping? > > # ipa -vv ping > ipa: INFO: trying https://nirvana.asteroids.phys.ucl.ac.uk/ipa/xml > ipa: INFO: Forwarding 'ping' to server > u'https://nirvana.asteroids.phys.ucl.ac.uk/ipa/xml' > send: u'POST /ipa/xml HTTP/1.0\r\nHost: > nirvana.asteroids.phys.ucl.ac.uk\r\nAccept-Language: en-gb\r\nReferer: > https://nirvana.asteroids.phys.ucl.ac.uk/ipa/xml\r\nAuthorization: > negotiate YIICjQYJKoZIhvcSAQICAQBuggJ8MIICeKADAgEFoQMCAQ6iBwMFACAAAACjggGDYYIBfzCCAXugAwIBBaEaGxhBU1RFUk9JRFMuUEhZUy5VQ0wuQUMuVUuiMzAxoAMCAQOhKjAoGwRIVFRQGyBuaXJ2YW5hLmFzdGVyb2lkcy5waHlzLnVjbC5hYy51a6OCASEwggEdoAMCARKhAwIBAqKCAQ8EggEL09s+S7cDtuzsWkvkvwYltApZCzFJ+fpEMB4Daw84x624iPeoIAeg9szUrU/V4h/nCB93rE5VRWP2N2abIEZfKiw6YzU+b4NXV7FftRWUuFI+YuHDPvtSoGkRIYpUebLOhBp+tdCly38u1EKPGqMX5EzcuqNCFaMWPKw14bc4DXZFGnKgO0vKWqT/OnBCfYhx9+5tNaJB7FHcKzzo4MA+NOooMKZCoPntLWAYCOA2IQjyX4FW6c+RkpDgq/NfG3JEEebHfZX50Cm5fYhjp2AqmZYdqZUfpuy/lcjmdBEAh0VkKa2+RPtz3fKS0KNuE23/ZJtR9zrd7i1QPQvb3m0oU4JP0xPdknV6KWowpIHbMIHYoAMCARKigdAEgc2S6M88mEbkZsIqK3dMsluzqtCiG23TTm1zLNh8cyJA9dQX0PaXXkf5NvPmpE2p9vsDmPvJCYHTNr2aKjBMp7FRTB1yaNuZWsxJXn7juqYa1paXTK7pLTHOt6QrkZM3PjvS9pYcHbpBBlgGTnGA0vr+ZthRr64gMTWIiRBtQ602R3DQokHKKYrWLrM97dOH5w4nw4GQ6z/tvUhvDVLtBwMJjNI6CUTtF/iA1j7CjEoUVC7y2kzIH6YjtNEn90DBWkT57rBCOJoF55+2TZF1\r\nUser-Agent: > xmlrpclib.py/1.0.1 (by www.pythonware.com)\r\nContent-Type: > text/xml\r\nContent-Length: 228\r\n\r\n' > ipa: ERROR: non-public: AttributeError: KerbTransport instance has no > attribute '_conn' > Traceback (most recent call last): > File "/usr/lib/python2.6/site-packages/ipalib/backend.py", line 129, > in execute > result = self.Command[_name](*args, **options) > File "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line > 435, in __call__ > ret = self.run(*args, **options) > File "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line 748, in run > return self.forward(*args, **options) > File "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line > 769, in forward > return self.Backend.xmlclient.forward(self.name, *args, **kw) > File "/usr/lib/python2.6/site-packages/ipalib/rpc.py", line 728, in forward > response = command(*xml_wrap(params)) > File "/usr/lib64/python2.6/xmlrpclib.py", line 1199, in __call__ > return self.__send(self.__name, args) > File "/usr/lib64/python2.6/xmlrpclib.py", line 1489, in __request > verbose=self.__verbose > File "/usr/lib/python2.6/site-packages/ipalib/rpc.py", line 475, in request > self.close() > File "/usr/lib/python2.6/site-packages/ipalib/rpc.py", line 442, in close > self._conn.close() > AttributeError: KerbTransport instance has no attribute '_conn' > ipa: ERROR: an internal error has occurred And with debug=True in default.conf: # ipa -vv ping ipa: DEBUG: importing all plugin modules in '/usr/lib/python2.6/site-packages/ipalib/plugins'... ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/aci.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/automember.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/automount.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/baseldap.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/batch.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/cert.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/config.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/delegation.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/dns.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/group.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/hbacrule.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/hbacsvc.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/hbacsvcgroup.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/hbactest.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/host.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/hostgroup.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/idrange.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/internal.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/kerberos.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/krbtpolicy.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/migration.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/misc.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/netgroup.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/passwd.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/permission.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/ping.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/privilege.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/pwpolicy.py' ipa: DEBUG: args=klist -V ipa: DEBUG: stdout=Kerberos 5 version 1.10.3 ipa: DEBUG: stderr= ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/role.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/selfservice.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/selinuxusermap.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/service.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/sudocmd.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/sudocmdgroup.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/sudorule.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/trust.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/user.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/virtual.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/xmlclient.py' ipa: DEBUG: args=keyctl search @s user ipa_session_cookie:admin at ASTEROIDS.PHYS.UCL.AC.UK ipa: DEBUG: stdout= ipa: DEBUG: stderr=keyctl_search: Required key not available ipa: DEBUG: failed to find session_cookie in persistent storage for principal 'admin at ASTEROIDS.PHYS.UCL.AC.UK' ipa: INFO: trying https://nirvana.asteroids.phys.ucl.ac.uk/ipa/xml ipa: DEBUG: Created connection context.xmlclient ipa: DEBUG: raw: ping() ipa: DEBUG: ping() ipa: INFO: Forwarding 'ping' to server u'https://nirvana.asteroids.phys.ucl.ac.uk/ipa/xml' ipa: DEBUG: NSSConnection init nirvana.asteroids.phys.ucl.ac.uk ipa: DEBUG: Connecting: 128.40.7.50:0 send: u'POST /ipa/xml HTTP/1.0\r\nHost: nirvana.asteroids.phys.ucl.ac.uk\r\nAccept-Language: en-gb\r\nReferer: https://nirvana.asteroids.phys.ucl.ac.uk/ipa/xml\r\nAuthorization: negotiate YIICjQYJKoZIhvcSAQICAQBuggJ8MIICeKADAgEFoQMCAQ6iBwMFACAAAACjggGDYYIBfzCCAXugAwIBBaEaGxhBU1RFUk9JRFMuUEhZUy5VQ0wuQUMuVUuiMzAxoAMCAQOhKjAoGwRIVFRQGyBuaXJ2YW5hLmFzdGVyb2lkcy5waHlzLnVjbC5hYy51a6OCASEwggEdoAMCARKhAwIBAqKCAQ8EggEL09s+S7cDtuzsWkvkvwYltApZCzFJ+fpEMB4Daw84x624iPeoIAeg9szUrU/V4h/nCB93rE5VRWP2N2abIEZfKiw6YzU+b4NXV7FftRWUuFI+YuHDPvtSoGkRIYpUebLOhBp+tdCly38u1EKPGqMX5EzcuqNCFaMWPKw14bc4DXZFGnKgO0vKWqT/OnBCfYhx9+5tNaJB7FHcKzzo4MA+NOooMKZCoPntLWAYCOA2IQjyX4FW6c+RkpDgq/NfG3JEEebHfZX50Cm5fYhjp2AqmZYdqZUfpuy/lcjmdBEAh0VkKa2+RPtz3fKS0KNuE23/ZJtR9zrd7i1QPQvb3m0oU4JP0xPdknV6KWowpIHbMIHYoAMCARKigdAEgc1nQEv6zQLi2IxdRVufVAAGfPKdkhCxtAczr+J0NnlOlabgMHmjD4oMBGuXAhxSFuNf/RDl1QlV3lG+dY/+ArSmqtYrXi8IiTva8iOaEHm0QZpOYv5e9qNcXR1sMtHlHixSV+cBORzkFDqcqGOUWLSRyPioq5OUBz97HhngAOZUWbRwbJc4bCU+jRHTIswMJsXP/NP+KF/SUYIxF76zbBxFCZ/R5Mq+uwVB0MahKyQ+PiPXxjb33O/VrhScxaTUMtNFkVDuT2kGYqjzoqPk\r\nUser-Agent: xmlrpclib.py/1.0.1 (by www.pythonware.com)\r\nContent-Type: text/xml\r\nContent-Length: 228\r\n\r\n' ipa: ERROR: non-public: AttributeError: KerbTransport instance has no attribute '_conn' Traceback (most recent call last): File "/usr/lib/python2.6/site-packages/ipalib/backend.py", line 129, in execute result = self.Command[_name](*args, **options) File "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line 435, in __call__ ret = self.run(*args, **options) File "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line 748, in run return self.forward(*args, **options) File "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line 769, in forward return self.Backend.xmlclient.forward(self.name, *args, **kw) File "/usr/lib/python2.6/site-packages/ipalib/rpc.py", line 728, in forward response = command(*xml_wrap(params)) File "/usr/lib64/python2.6/xmlrpclib.py", line 1199, in __call__ return self.__send(self.__name, args) File "/usr/lib64/python2.6/xmlrpclib.py", line 1489, in __request verbose=self.__verbose File "/usr/lib/python2.6/site-packages/ipalib/rpc.py", line 475, in request self.close() File "/usr/lib/python2.6/site-packages/ipalib/rpc.py", line 442, in close self._conn.close() AttributeError: KerbTransport instance has no attribute '_conn' ipa: DEBUG: Destroyed connection context.xmlclient ipa: ERROR: an internal error has occurred Sooo.... I think that means the problem lies with apache and NSS, right? From jonathan.underwood at gmail.com Fri Nov 8 12:50:21 2013 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Fri, 8 Nov 2013 12:50:21 +0000 Subject: [Freeipa-users] ipa cli AttributeError: KerbTransport instance has no attribute '_conn' In-Reply-To: <527C17FC.8000301@redhat.com> References: <527C17FC.8000301@redhat.com> Message-ID: On 7 November 2013 22:45, Rob Crittenden wrote: > This is it trying to close a connection that was never made. > > Can you run ipa -vv ping? # ipa -vv ping ipa: INFO: trying https://nirvana.asteroids.phys.ucl.ac.uk/ipa/xml ipa: INFO: Forwarding 'ping' to server u'https://nirvana.asteroids.phys.ucl.ac.uk/ipa/xml' send: u'POST /ipa/xml HTTP/1.0\r\nHost: nirvana.asteroids.phys.ucl.ac.uk\r\nAccept-Language: en-gb\r\nReferer: https://nirvana.asteroids.phys.ucl.ac.uk/ipa/xml\r\nAuthorization: negotiate YIICjQYJKoZIhvcSAQICAQBuggJ8MIICeKADAgEFoQMCAQ6iBwMFACAAAACjggGDYYIBfzCCAXugAwIBBaEaGxhBU1RFUk9JRFMuUEhZUy5VQ0wuQUMuVUuiMzAxoAMCAQOhKjAoGwRIVFRQGyBuaXJ2YW5hLmFzdGVyb2lkcy5waHlzLnVjbC5hYy51a6OCASEwggEdoAMCARKhAwIBAqKCAQ8EggEL09s+S7cDtuzsWkvkvwYltApZCzFJ+fpEMB4Daw84x624iPeoIAeg9szUrU/V4h/nCB93rE5VRWP2N2abIEZfKiw6YzU+b4NXV7FftRWUuFI+YuHDPvtSoGkRIYpUebLOhBp+tdCly38u1EKPGqMX5EzcuqNCFaMWPKw14bc4DXZFGnKgO0vKWqT/OnBCfYhx9+5tNaJB7FHcKzzo4MA+NOooMKZCoPntLWAYCOA2IQjyX4FW6c+RkpDgq/NfG3JEEebHfZX50Cm5fYhjp2AqmZYdqZUfpuy/lcjmdBEAh0VkKa2+RPtz3fKS0KNuE23/ZJtR9zrd7i1QPQvb3m0oU4JP0xPdknV6KWowpIHbMIHYoAMCARKigdAEgc2S6M88mEbkZsIqK3dMsluzqtCiG23TTm1zLNh8cyJA9dQX0PaXXkf5NvPmpE2p9vsDmPvJCYHTNr2aKjBMp7FRTB1yaNuZWsxJXn7juqYa1paXTK7pLTHOt6QrkZM3PjvS9pYcHbpBBlgGTnGA0vr+ZthRr64gMTWIiRBtQ602R3DQokHKKYrWLrM97dOH5w4nw4GQ6z/tvUhvDVLtBwMJjNI6CUTtF/iA1j7CjEoUVC7y2kzIH6YjtNEn90DBWkT57rBCOJoF55+2TZF1\r\nUser-Agent: xmlrpclib.py/1.0.1 (by www.pythonware.com)\r\nContent-Type: text/xml\r\nContent-Length: 228\r\n\r\n' ipa: ERROR: non-public: AttributeError: KerbTransport instance has no attribute '_conn' Traceback (most recent call last): File "/usr/lib/python2.6/site-packages/ipalib/backend.py", line 129, in execute result = self.Command[_name](*args, **options) File "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line 435, in __call__ ret = self.run(*args, **options) File "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line 748, in run return self.forward(*args, **options) File "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line 769, in forward return self.Backend.xmlclient.forward(self.name, *args, **kw) File "/usr/lib/python2.6/site-packages/ipalib/rpc.py", line 728, in forward response = command(*xml_wrap(params)) File "/usr/lib64/python2.6/xmlrpclib.py", line 1199, in __call__ return self.__send(self.__name, args) File "/usr/lib64/python2.6/xmlrpclib.py", line 1489, in __request verbose=self.__verbose File "/usr/lib/python2.6/site-packages/ipalib/rpc.py", line 475, in request self.close() File "/usr/lib/python2.6/site-packages/ipalib/rpc.py", line 442, in close self._conn.close() AttributeError: KerbTransport instance has no attribute '_conn' ipa: ERROR: an internal error has occurred From dpal at redhat.com Fri Nov 8 13:46:08 2013 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 08 Nov 2013 08:46:08 -0500 Subject: [Freeipa-users] ipa cli AttributeError: KerbTransport instance has no attribute '_conn' In-Reply-To: References: <527C17FC.8000301@redhat.com> Message-ID: <527CEB20.5090504@redhat.com> On 11/08/2013 08:17 AM, Jonathan Underwood wrote: > On 8 November 2013 12:50, Jonathan Underwood > wrote: >> On 7 November 2013 22:45, Rob Crittenden wrote: >>> This is it trying to close a connection that was never made. >>> >>> Can you run ipa -vv ping? >> # ipa -vv ping >> ipa: INFO: trying https://nirvana.asteroids.phys.ucl.ac.uk/ipa/xml >> ipa: INFO: Forwarding 'ping' to server >> u'https://nirvana.asteroids.phys.ucl.ac.uk/ipa/xml' >> send: u'POST /ipa/xml HTTP/1.0\r\nHost: >> nirvana.asteroids.phys.ucl.ac.uk\r\nAccept-Language: en-gb\r\nReferer: >> https://nirvana.asteroids.phys.ucl.ac.uk/ipa/xml\r\nAuthorization: >> negotiate YIICjQYJKoZIhvcSAQICAQBuggJ8MIICeKADAgEFoQMCAQ6iBwMFACAAAACjggGDYYIBfzCCAXugAwIBBaEaGxhBU1RFUk9JRFMuUEhZUy5VQ0wuQUMuVUuiMzAxoAMCAQOhKjAoGwRIVFRQGyBuaXJ2YW5hLmFzdGVyb2lkcy5waHlzLnVjbC5hYy51a6OCASEwggEdoAMCARKhAwIBAqKCAQ8EggEL09s+S7cDtuzsWkvkvwYltApZCzFJ+fpEMB4Daw84x624iPeoIAeg9szUrU/V4h/nCB93rE5VRWP2N2abIEZfKiw6YzU+b4NXV7FftRWUuFI+YuHDPvtSoGkRIYpUebLOhBp+tdCly38u1EKPGqMX5EzcuqNCFaMWPKw14bc4DXZFGnKgO0vKWqT/OnBCfYhx9+5tNaJB7FHcKzzo4MA+NOooMKZCoPntLWAYCOA2IQjyX4FW6c+RkpDgq/NfG3JEEebHfZX50Cm5fYhjp2AqmZYdqZUfpuy/lcjmdBEAh0VkKa2+RPtz3fKS0KNuE23/ZJtR9zrd7i1QPQvb3m0oU4JP0xPdknV6KWowpIHbMIHYoAMCARKigdAEgc2S6M88mEbkZsIqK3dMsluzqtCiG23TTm1zLNh8cyJA9dQX0PaXXkf5NvPmpE2p9vsDmPvJCYHTNr2aKjBMp7FRTB1yaNuZWsxJXn7juqYa1paXTK7pLTHOt6QrkZM3PjvS9pYcHbpBBlgGTnGA0vr+ZthRr64gMTWIiRBtQ602R3DQokHKKYrWLrM97dOH5w4nw4GQ6z/tvUhvDVLtBwMJjNI6CUTtF/iA1j7CjEoUVC7y2kzIH6YjtNEn90DBWkT57rBCOJoF55+2TZF1\r\nUser-Agent: >> xmlrpclib.py/1.0.1 (by www.pythonware.com)\r\nContent-Type: >> text/xml\r\nContent-Length: 228\r\n\r\n' >> ipa: ERROR: non-public: AttributeError: KerbTransport instance has no >> attribute '_conn' >> Traceback (most recent call last): >> File "/usr/lib/python2.6/site-packages/ipalib/backend.py", line 129, >> in execute >> result = self.Command[_name](*args, **options) >> File "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line >> 435, in __call__ >> ret = self.run(*args, **options) >> File "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line 748, in run >> return self.forward(*args, **options) >> File "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line >> 769, in forward >> return self.Backend.xmlclient.forward(self.name, *args, **kw) >> File "/usr/lib/python2.6/site-packages/ipalib/rpc.py", line 728, in forward >> response = command(*xml_wrap(params)) >> File "/usr/lib64/python2.6/xmlrpclib.py", line 1199, in __call__ >> return self.__send(self.__name, args) >> File "/usr/lib64/python2.6/xmlrpclib.py", line 1489, in __request >> verbose=self.__verbose >> File "/usr/lib/python2.6/site-packages/ipalib/rpc.py", line 475, in request >> self.close() >> File "/usr/lib/python2.6/site-packages/ipalib/rpc.py", line 442, in close >> self._conn.close() >> AttributeError: KerbTransport instance has no attribute '_conn' >> ipa: ERROR: an internal error has occurred > And with debug=True in default.conf: > > # ipa -vv ping > ipa: DEBUG: importing all plugin modules in > '/usr/lib/python2.6/site-packages/ipalib/plugins'... > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/aci.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/automember.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/automount.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/baseldap.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/batch.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/cert.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/config.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/delegation.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/dns.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/group.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/hbacrule.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/hbacsvc.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/hbacsvcgroup.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/hbactest.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/host.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/hostgroup.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/idrange.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/internal.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/kerberos.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/krbtpolicy.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/migration.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/misc.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/netgroup.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/passwd.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/permission.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/ping.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/privilege.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/pwpolicy.py' > ipa: DEBUG: args=klist -V > ipa: DEBUG: stdout=Kerberos 5 version 1.10.3 > > ipa: DEBUG: stderr= > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/role.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/selfservice.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/selinuxusermap.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/service.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/sudocmd.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/sudocmdgroup.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/sudorule.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/trust.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/user.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/virtual.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/xmlclient.py' > ipa: DEBUG: args=keyctl search @s user > ipa_session_cookie:admin at ASTEROIDS.PHYS.UCL.AC.UK > ipa: DEBUG: stdout= > ipa: DEBUG: stderr=keyctl_search: Required key not available > > ipa: DEBUG: failed to find session_cookie in persistent storage for > principal 'admin at ASTEROIDS.PHYS.UCL.AC.UK' > ipa: INFO: trying https://nirvana.asteroids.phys.ucl.ac.uk/ipa/xml > ipa: DEBUG: Created connection context.xmlclient > ipa: DEBUG: raw: ping() > ipa: DEBUG: ping() > ipa: INFO: Forwarding 'ping' to server > u'https://nirvana.asteroids.phys.ucl.ac.uk/ipa/xml' > ipa: DEBUG: NSSConnection init nirvana.asteroids.phys.ucl.ac.uk > ipa: DEBUG: Connecting: 128.40.7.50:0 > send: u'POST /ipa/xml HTTP/1.0\r\nHost: > nirvana.asteroids.phys.ucl.ac.uk\r\nAccept-Language: en-gb\r\nReferer: > https://nirvana.asteroids.phys.ucl.ac.uk/ipa/xml\r\nAuthorization: > negotiate YIICjQYJKoZIhvcSAQICAQBuggJ8MIICeKADAgEFoQMCAQ6iBwMFACAAAACjggGDYYIBfzCCAXugAwIBBaEaGxhBU1RFUk9JRFMuUEhZUy5VQ0wuQUMuVUuiMzAxoAMCAQOhKjAoGwRIVFRQGyBuaXJ2YW5hLmFzdGVyb2lkcy5waHlzLnVjbC5hYy51a6OCASEwggEdoAMCARKhAwIBAqKCAQ8EggEL09s+S7cDtuzsWkvkvwYltApZCzFJ+fpEMB4Daw84x624iPeoIAeg9szUrU/V4h/nCB93rE5VRWP2N2abIEZfKiw6YzU+b4NXV7FftRWUuFI+YuHDPvtSoGkRIYpUebLOhBp+tdCly38u1EKPGqMX5EzcuqNCFaMWPKw14bc4DXZFGnKgO0vKWqT/OnBCfYhx9+5tNaJB7FHcKzzo4MA+NOooMKZCoPntLWAYCOA2IQjyX4FW6c+RkpDgq/NfG3JEEebHfZX50Cm5fYhjp2AqmZYdqZUfpuy/lcjmdBEAh0VkKa2+RPtz3fKS0KNuE23/ZJtR9zrd7i1QPQvb3m0oU4JP0xPdknV6KWowpIHbMIHYoAMCARKigdAEgc1nQEv6zQLi2IxdRVufVAAGfPKdkhCxtAczr+J0NnlOlabgMHmjD4oMBGuXAhxSFuNf/RDl1QlV3lG+dY/+ArSmqtYrXi8IiTva8iOaEHm0QZpOYv5e9qNcXR1sMtHlHixSV+cBORzkFDqcqGOUWLSRyPioq5OUBz97HhngAOZUWbRwbJc4bCU+jRHTIswMJsXP/NP+KF/SUYIxF76zbBxFCZ/R5Mq+uwVB0MahKyQ+PiPXxjb33O/VrhScxaTUMtNFkVDuT2kGYqjzoqPk\r\nUser-Agent: > xmlrpclib.py/1.0.1 (by www.pythonware.com)\r\nContent-Type: > text/xml\r\nContent-Length: 228\r\n\r\n' > ipa: ERROR: non-public: AttributeError: KerbTransport instance has no > attribute '_conn' > Traceback (most recent call last): > File "/usr/lib/python2.6/site-packages/ipalib/backend.py", line 129, > in execute > result = self.Command[_name](*args, **options) > File "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line > 435, in __call__ > ret = self.run(*args, **options) > File "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line 748, in run > return self.forward(*args, **options) > File "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line > 769, in forward > return self.Backend.xmlclient.forward(self.name, *args, **kw) > File "/usr/lib/python2.6/site-packages/ipalib/rpc.py", line 728, in forward > response = command(*xml_wrap(params)) > File "/usr/lib64/python2.6/xmlrpclib.py", line 1199, in __call__ > return self.__send(self.__name, args) > File "/usr/lib64/python2.6/xmlrpclib.py", line 1489, in __request > verbose=self.__verbose > File "/usr/lib/python2.6/site-packages/ipalib/rpc.py", line 475, in request > self.close() > File "/usr/lib/python2.6/site-packages/ipalib/rpc.py", line 442, in close > self._conn.close() > AttributeError: KerbTransport instance has no attribute '_conn' > ipa: DEBUG: Destroyed connection context.xmlclient > ipa: ERROR: an internal error has occurred > > > Sooo.... I think that means the problem lies with apache and NSS, right? Or in the negotiated authentication. Is there anything in the kerberos logs on the server side? Can you do an ldap connection using GSSAPI from the client? May be KDC is not accessible because FW does allow access to the KDC port? Just some ideas what to check... > > _______________________________________________ > 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 jdennis at redhat.com Fri Nov 8 13:53:37 2013 From: jdennis at redhat.com (John Dennis) Date: Fri, 08 Nov 2013 08:53:37 -0500 Subject: [Freeipa-users] External CA In-Reply-To: <527CB54B.1080808@redhat.com> References: <527A47AE.9070607@redhat.com> <527B7B5B.9000200@redhat.com> <527C9A3C.9000008@redhat.com> <527CB54B.1080808@redhat.com> Message-ID: <527CECE1.9080300@redhat.com> On 11/08/2013 04:56 AM, Petr Viktorin wrote: > On 11/08/2013 09:01 AM, Martin Kosek wrote: >> Thanks for heads up. You mean by the difference between "O=MW" and >> "O=MELTWATER.COM"? >> Petr, is this possible? Can it be validated in the the installer if this is the >> root cause? Thats a good question. Typically with cert validation only the CN component in the subject is cross checked. More aggressive validators are free to examine all RDN's in the subject (not sure what the PKIX behavior is with respect other RDN's). Of course this isn't cert validation but validating a CSR is closely related. The first place I would look is the Dogtag policy. > It is possible. It's hard to tell without the logs; looks like the > failure was inside Dogtag. There may be more issues; for instance I > don't think we considered PEM files with extra data before the BEGIN > CERTIFICATE. > I filed a ticket to investigate: > https://fedorahosted.org/freeipa/ticket/4019 FWIW I've authored a set of Python utilities to work with pem files for OpenStack. They work just fine with PEM blocks embedded with non-PEM text. I was thinking the utilities would also be useful in FreeIPA (in fact my experience in IPA is what guided the development of these utilities. I'll try to get them up in a git repo shortly and send a pointer. -- John From jonathan.underwood at gmail.com Fri Nov 8 14:00:50 2013 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Fri, 8 Nov 2013 14:00:50 +0000 Subject: [Freeipa-users] ipa cli AttributeError: KerbTransport instance has no attribute '_conn' In-Reply-To: <527CEB20.5090504@redhat.com> References: <527C17FC.8000301@redhat.com> <527CEB20.5090504@redhat.com> Message-ID: On 8 November 2013 13:46, Dmitri Pal wrote: > On 11/08/2013 08:17 AM, Jonathan Underwood wrote: >> Sooo.... I think that means the problem lies with apache and NSS, right? > > > Or in the negotiated authentication. > Is there anything in the kerberos logs on the server side? Nothing error wise. > Can you do an ldap connection using GSSAPI from the client? Yep. (Note the client machine in all my tests has actually been the same machine as the server). > May be KDC is not accessible because FW does allow access to the KDC port? > Nope, tisn't that, have stopped the iptables service, and also done a setenforce 0. > Just some ideas what to check... > OK, I am getting closer to diagnosing the problem. On the server machine I had also configured apache to serve up another name based vhost. Removing that vhost config and restarting httpd caused the ipa ping command to work successfully. So, this seems to be a problem with httpd/mod_nss and hosting IPA and other vhosts. Note the other vhost wasn't using nss or ssl. I'll dig some more. From rcritten at redhat.com Fri Nov 8 14:18:52 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 08 Nov 2013 09:18:52 -0500 Subject: [Freeipa-users] FreeIPA 3.3.* bug with external-ca? In-Reply-To: <1731723855.43033.1383915507386.JavaMail.root@dbmsrl.com> References: <1731723855.43033.1383915507386.JavaMail.root@dbmsrl.com> Message-ID: <527CF2CC.7030607@redhat.com> Andrea Bontempi wrote: > Hi, i'm trying to install FreeIPA with external CA (again) > > Now i use FreeIPA 3.3.* and i found a strange error on "[17/22]: requesting RA certificate from CA": > >> 2013-11-08T11:07:38Z DEBUG File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 622, in run_script >> return_value = main_function() >> >> File "/usr/sbin/ipa-server-install", line 1096, in main >> subject_base=options.subject) >> >> File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 478, in configure_instance >> self.start_creation(runtime=210) >> >> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 364, in start_creation >> method() >> >> File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 1089, in __request_ra_certificate >> self.requestId = item_node[0].childNodes[0].data >> >> 2013-11-08T11:07:38Z DEBUG The ipa-server-install command failed, exception: IndexError: list index out of range > > So, i open /usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py on the line 1089: > >> # Send the request to the CA >> conn = httplib.HTTPConnection( >> self.fqdn, self.dogtag_constants.UNSECURE_PORT) >> params = urllib.urlencode({'profileId': 'caServerCert', >> 'cert_request_type': 'pkcs10', >> 'requestor_name': 'IPA Installer', >> 'cert_request': csr, >> 'xmlOutput': 'true'}) >> headers = {"Content-type": "application/x-www-form-urlencoded", >> "Accept": "text/plain"} >> >> conn.request("POST", "/ca/ee/ca/profileSubmit", params, headers) >> res = conn.getresponse() >> if res.status == 200: >> data = res.read() >> conn.close() >> doc = xml.dom.minidom.parseString(data) >> item_node = doc.getElementsByTagName("RequestId") >> self.requestId = item_node[0].childNodes[0].data <-- exception: IndexError: list index out of range >> doc.unlink() >> self.requestId = self.requestId.strip() >> if self.requestId is None: >> raise RuntimeError("Unable to determine RA certificate requestId") > > I read the value of "data": > >> >> >> 1 >> Profile caServerCert Not Found >> > > Can someone help me? I'd check out the CA logs in /var/log/pki/pki-tomcat/ca for more information. rob From abontempi at dbmsrl.com Fri Nov 8 14:31:52 2013 From: abontempi at dbmsrl.com (Andrea Bontempi) Date: Fri, 8 Nov 2013 15:31:52 +0100 (CET) Subject: [Freeipa-users] FreeIPA 3.3.* bug with external-ca? In-Reply-To: <527CF2CC.7030607@redhat.com> References: <1731723855.43033.1383915507386.JavaMail.root@dbmsrl.com> <527CF2CC.7030607@redhat.com> Message-ID: <816077283.43223.1383921112030.JavaMail.root@dbmsrl.com> Here the log /var/log/pki/pki-tomcat/ca/debug [08/nov/2013:13:40:43][http-bio-8080-exec-2]: according to ccMode, authorization for servlet: caProfileSubmit is LDAP based, not XML {1}, use default authz mgr: {2}. [08/nov/2013:13:40:43][http-bio-8080-exec-2]: according to ccMode, authorization for servlet: caProfileSubmit is LDAP based, not XML {1}, use default authz mgr: {2}. [08/nov/2013:13:40:43][http-bio-8080-exec-2]: CMSServlet:service() uri = /ca/ee/ca/profileSubmit [08/nov/2013:13:40:43][http-bio-8080-exec-2]: CMSServlet::service() param name='xmlOutput' value='true' [08/nov/2013:13:40:43][http-bio-8080-exec-2]: CMSServlet::service() param name='requestor_name' value='IPA Installer' [08/nov/2013:13:40:43][http-bio-8080-exec-2]: CMSServlet::service() param name='profileId' value='caServerCert' [08/nov/2013:13:40:43][http-bio-8080-exec-2]: CMSServlet::service() param name='cert_request_type' value='pkcs10' [08/nov/2013:13:40:43][http-bio-8080-exec-2]: CMSServlet::service() param name='cert_request' value='MIICazCCAVMCAQ...[omissis]' [08/nov/2013:13:40:43][http-bio-8080-exec-2]: CMSServlet: caProfileSubmit start to service. [08/nov/2013:13:40:43][http-bio-8080-exec-2]: xmlOutput true [08/nov/2013:13:40:43][http-bio-8080-exec-2]: ProfileSubmitServlet: isRenewal false [08/nov/2013:13:40:43][http-bio-8080-exec-2]: according to ccMode, authorization for servlet: caProfileSubmit is LDAP based, not XML {1}, use default authz mgr: {2}. [08/nov/2013:13:40:43][http-bio-8080-exec-2]: Profile caServerCert Not Found [08/nov/2013:13:40:43][http-bio-8080-exec-2]: ProfileSubmitServlet: bad data provided in processing request: Profile caServerCert Not Found [08/nov/2013:13:40:43][http-bio-8080-exec-2]: CMSServlet: curDate=Fri Nov 08 13:40:43 CET 2013 id=caProfileSubmit time=100 Log /var/log/pki/pki-tomcat/ca/system: 1434.http-bio-8443-exec-3 - [08/nov/2013:13:37:38 CET] [3] [3] Cannot build CA chain. Error java.security.cert.CertificateException: Certificate is not a PKCS #11 certificate 1434.http-bio-8443-exec-7 - [08/nov/2013:13:40:19 CET] [3] [3] CASigningUnit: Object certificate not found. Error org.mozilla.jss.crypto.ObjectNotFoundException Thank you From rcritten at redhat.com Fri Nov 8 14:41:50 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 08 Nov 2013 09:41:50 -0500 Subject: [Freeipa-users] FreeIPA 3.3.* bug with external-ca? In-Reply-To: <816077283.43223.1383921112030.JavaMail.root@dbmsrl.com> References: <1731723855.43033.1383915507386.JavaMail.root@dbmsrl.com> <527CF2CC.7030607@redhat.com> <816077283.43223.1383921112030.JavaMail.root@dbmsrl.com> Message-ID: <527CF82E.7090604@redhat.com> Andrea Bontempi wrote: > Here the log /var/log/pki/pki-tomcat/ca/debug > > [08/nov/2013:13:40:43][http-bio-8080-exec-2]: according to ccMode, authorization for servlet: caProfileSubmit is LDAP based, not XML {1}, use default authz mgr: {2}. > [08/nov/2013:13:40:43][http-bio-8080-exec-2]: according to ccMode, authorization for servlet: caProfileSubmit is LDAP based, not XML {1}, use default authz mgr: {2}. > [08/nov/2013:13:40:43][http-bio-8080-exec-2]: CMSServlet:service() uri = /ca/ee/ca/profileSubmit > [08/nov/2013:13:40:43][http-bio-8080-exec-2]: CMSServlet::service() param name='xmlOutput' value='true' > [08/nov/2013:13:40:43][http-bio-8080-exec-2]: CMSServlet::service() param name='requestor_name' value='IPA Installer' > [08/nov/2013:13:40:43][http-bio-8080-exec-2]: CMSServlet::service() param name='profileId' value='caServerCert' > [08/nov/2013:13:40:43][http-bio-8080-exec-2]: CMSServlet::service() param name='cert_request_type' value='pkcs10' > [08/nov/2013:13:40:43][http-bio-8080-exec-2]: CMSServlet::service() param name='cert_request' value='MIICazCCAVMCAQ...[omissis]' > [08/nov/2013:13:40:43][http-bio-8080-exec-2]: CMSServlet: caProfileSubmit start to service. > [08/nov/2013:13:40:43][http-bio-8080-exec-2]: xmlOutput true > [08/nov/2013:13:40:43][http-bio-8080-exec-2]: ProfileSubmitServlet: isRenewal false > [08/nov/2013:13:40:43][http-bio-8080-exec-2]: according to ccMode, authorization for servlet: caProfileSubmit is LDAP based, not XML {1}, use default authz mgr: {2}. > [08/nov/2013:13:40:43][http-bio-8080-exec-2]: Profile caServerCert Not Found > [08/nov/2013:13:40:43][http-bio-8080-exec-2]: ProfileSubmitServlet: bad data provided in processing request: Profile caServerCert Not Found > [08/nov/2013:13:40:43][http-bio-8080-exec-2]: CMSServlet: curDate=Fri Nov 08 13:40:43 CET 2013 id=caProfileSubmit time=100 > > Log /var/log/pki/pki-tomcat/ca/system: > > 1434.http-bio-8443-exec-3 - [08/nov/2013:13:37:38 CET] [3] [3] Cannot build CA chain. Error java.security.cert.CertificateException: Certificate is not a PKCS #11 certificate > 1434.http-bio-8443-exec-7 - [08/nov/2013:13:40:19 CET] [3] [3] CASigningUnit: Object certificate not found. Error org.mozilla.jss.crypto.ObjectNotFoundException Ok, I'm not sure if the caServerCert error is a red herring or not. Does /usr/share/pki/ca/profiles/ca/caServerCert.cfg exist? Does rpm -V pki-ca pass? I wonder if the certificate you're passing is valid. Can openssl x509 -text -in /path/to/ca.crt show the cert ok? rob From abontempi at dbmsrl.com Fri Nov 8 14:55:57 2013 From: abontempi at dbmsrl.com (Andrea Bontempi) Date: Fri, 8 Nov 2013 15:55:57 +0100 (CET) Subject: [Freeipa-users] FreeIPA 3.3.* bug with external-ca? In-Reply-To: <527CF82E.7090604@redhat.com> References: <1731723855.43033.1383915507386.JavaMail.root@dbmsrl.com> <527CF2CC.7030607@redhat.com> <816077283.43223.1383921112030.JavaMail.root@dbmsrl.com> <527CF82E.7090604@redhat.com> Message-ID: <527583967.43306.1383922557138.JavaMail.root@dbmsrl.com> > /usr/share/pki/ca/profiles/ca/caServerCert.cfg exist? Yes > Does rpm -V pki-ca pass? No response > Can openssl x509 -text -in /path/to/ca.crt show the cert ok? Certificate: Data: Version: 3 (0x2) Serial Number: 1383914316 (0x527cdb4c) Signature Algorithm: sha1WithRSAEncryption Issuer: CN=DBM Validity Not Before: Nov 8 12:38:37 2013 GMT Not After : Feb 16 12:38:38 2014 GMT Subject: O=DBMSRL.COM, CN=Certificate Authority Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:d9:4b... [omissis] Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: critical CA:TRUE X509v3 Subject Alternative Name: email:dbm at dbmsrl.com X509v3 Extended Key Usage: Code Signing, OCSP Signing, Time Stamping X509v3 Key Usage: critical Certificate Sign, CRL Sign X509v3 Subject Key Identifier: 2D:21:C5:07... [omissis] X509v3 Authority Key Identifier: keyid:2A:B7... [omissis] From isaev at fintech.ru Fri Nov 8 15:22:57 2013 From: isaev at fintech.ru (=?koi8-r?B?6dPBxdcg98nUwczJyiDhzsHUz8zYxdfJ3g==?=) Date: Fri, 8 Nov 2013 15:22:57 +0000 Subject: [Freeipa-users] Access differentiation in group policy Message-ID: <69303615BE133645963548DD4A3BFCB3A610B9@E2K7.fintech.ru> Dear colleagues, we faced with an issue of access differentiation for junior IPA admins. Our idea was to create several (say, three - group1, group2, group3) isolated groups with one junior admin per group. The group isolation means that admin of group1 is not able to add to his group neither users nor subgroups - members of other global groups (i.e. group2, group3) We have attempted to accomplish this by RBAC for every junior admin. It was pointed out, that the admin can modify the objects (users, subgroups) belonging to his group only. However, every user enrolled to IPA can see all the other objects by default, therefore any junior admin can add users and subgroups FROM THE OTHER isolated group to his group with no restrictions. So the question is - how to implement (the specified) group "isolation" in IPA? We're running on the RHEL 6.4 with IPA 3.0. Thank you. Vitaly Isaev Software Engineer Information Security Department Fintech JSC -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdennis at redhat.com Fri Nov 8 15:30:53 2013 From: jdennis at redhat.com (John Dennis) Date: Fri, 08 Nov 2013 10:30:53 -0500 Subject: [Freeipa-users] External CA In-Reply-To: <527CECE1.9080300@redhat.com> References: <527A47AE.9070607@redhat.com> <527B7B5B.9000200@redhat.com> <527C9A3C.9000008@redhat.com> <527CB54B.1080808@redhat.com> <527CECE1.9080300@redhat.com> Message-ID: <527D03AD.4060606@redhat.com> On 11/08/2013 08:53 AM, John Dennis wrote: > FWIW I've authored a set of Python utilities to work with pem files for > OpenStack. They work just fine with PEM blocks embedded with non-PEM > text. I was thinking the utilities would also be useful in FreeIPA (in > fact my experience in IPA is what guided the development of these > utilities. I'll try to get them up in a git repo shortly and send a pointer. Done. git clone git://fedorapeople.org/~jdennis/utilities.git Look in the x509 subdirectory, there are also unittests for both modules. -- John From rcritten at redhat.com Fri Nov 8 15:46:29 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 08 Nov 2013 10:46:29 -0500 Subject: [Freeipa-users] Access differentiation in group policy In-Reply-To: <69303615BE133645963548DD4A3BFCB3A610B9@E2K7.fintech.ru> References: <69303615BE133645963548DD4A3BFCB3A610B9@E2K7.fintech.ru> Message-ID: <527D0755.2030904@redhat.com> ????? ??????? ??????????? wrote: > Dear colleagues, we faced with an issue of access differentiation for > junior IPA admins. Our idea was to create several (say, three ? group1, > group2, group3) isolated groups with one junior admin per group. > > The group isolation means that admin of group1 is not able to add to his > group neither users nor subgroups ? members of other global groups (i.e. > group2, group3) > > We have attempted to accomplish this by RBAC for every junior admin. It > was pointed out, that the admin can modify the objects (users, > subgroups) belonging to his group only. However, every user enrolled to > IPA can see all the other objects by default, therefore any junior admin > can add users and subgroups FROM THE OTHER isolated group to his group > with no restrictions. > > So the question is ? how to implement (the specified) group ?isolation? > in IPA? > > We?re running on the RHEL 6.4 with IPA 3.0. Thank you. You need to create some custom permissions that limit the capabilities by memberof. I set up a simple system with a couple of users: kinit admin ipa group-add --desc=g1 g1 ipa group-add --desc=g2 g2 ipa user-add --first=group1 --last=user1 g1u1 ipa user-add --first=group2 --last=user1 g2u1 ipa group-add-member --users g1u1 g1 ipa group-add-member --users g2u1 g2 ipa user-add --first=group1 --last=admin1 g1a1 ipa group-add-member --users g1a1 g1 ipa passwd g1a1 g1a1 is going to be my junior admin Next I created a permission so junior admins can manage the telephone number. This permission allows the phone number attribute to be written only for members of the group g1. ipa permission-add --attrs=telephonenumber --memberof=g1 --permissions=write g1_modify_members ipa privilege-add g1_junior_admin --desc='Group 1 junior admin' ipa privilege-add-permission --permissions=g1_modify_members g1_junior_admin ipa role-add --desc='Group 1 junior admin' group1 ipa role-add-privilege --privileges=g1_junior_admin group1 ipa role-add-member --users=g1a1 group1 So members of the group1 role can modify the telephonenumber attribute of its members. Let's see it in action: kinit g1a1 ipa user-mod --phone=410-555-1212 g1u1 -------------------- Modified user "g1u1" -------------------- User login: g1u1 First name: group1 Last name: user1 Home directory: /home/g1u1 Login shell: /bin/sh Email address: g1u1 at example.com UID: 1197000004 GID: 1197000004 Telephone Number: 410-555-1212 Account disabled: False Password: False Member of groups: ipausers, g1 Kerberos keys available: False Try another attribute and it fails as expected: ipa user-mod --fax=410-555-1212 g1u1 ipa: ERROR: Insufficient access: Insufficient 'write' privilege to the 'facsimileTelephoneNumber' attribute of entry 'uid=g1u1,cn=users,cn=accounts,dc=example,dc=com'. Change the phone number of a non-member of the group and it also fails as expected: ipa user-mod --phone=410-555-1213 g2u1 ipa: ERROR: Insufficient access: Insufficient 'write' privilege to the 'telephoneNumber' attribute of entry 'uid=g2u1,cn=users,cn=accounts,dc=example,dc=com'. rob From isaev at fintech.ru Fri Nov 8 15:53:10 2013 From: isaev at fintech.ru (=?utf-8?B?0JjRgdCw0LXQsiDQktC40YLQsNC70LjQuSDQkNC90LDRgtC+0LvRjNC10LI=?= =?utf-8?B?0LjRhw==?=) Date: Fri, 8 Nov 2013 15:53:10 +0000 Subject: [Freeipa-users] Access differentiation in group policy In-Reply-To: <527D0755.2030904@redhat.com> References: <69303615BE133645963548DD4A3BFCB3A610B9@E2K7.fintech.ru> <527D0755.2030904@redhat.com> Message-ID: <69303615BE133645963548DD4A3BFCB3A610DF@E2K7.fintech.ru> Thank you, Rob! This example is very useful. Vitaly Isaev Software Engineer Information Security Department Fintech JSC -----Original Message----- From: Rob Crittenden [mailto:rcritten at redhat.com] Sent: Friday, November 08, 2013 7:47 PM To: ????? ??????? ???????????; freeipa-users at redhat.com Subject: Re: [Freeipa-users] Access differentiation in group policy ????? ??????? ??????????? wrote: > Dear colleagues, we faced with an issue of access differentiation for > junior IPA admins. Our idea was to create several (say, three ? > group1, group2, group3) isolated groups with one junior admin per group. > > The group isolation means that admin of group1 is not able to add to > his group neither users nor subgroups ? members of other global groups (i.e. > group2, group3) > > We have attempted to accomplish this by RBAC for every junior admin. > It was pointed out, that the admin can modify the objects (users, > subgroups) belonging to his group only. However, every user enrolled > to IPA can see all the other objects by default, therefore any junior > admin can add users and subgroups FROM THE OTHER isolated group to his > group with no restrictions. > > So the question is ? how to implement (the specified) group ?isolation? > in IPA? > > We?re running on the RHEL 6.4 with IPA 3.0. Thank you. You need to create some custom permissions that limit the capabilities by memberof. I set up a simple system with a couple of users: kinit admin ipa group-add --desc=g1 g1 ipa group-add --desc=g2 g2 ipa user-add --first=group1 --last=user1 g1u1 ipa user-add --first=group2 --last=user1 g2u1 ipa group-add-member --users g1u1 g1 ipa group-add-member --users g2u1 g2 ipa user-add --first=group1 --last=admin1 g1a1 ipa group-add-member --users g1a1 g1 ipa passwd g1a1 g1a1 is going to be my junior admin Next I created a permission so junior admins can manage the telephone number. This permission allows the phone number attribute to be written only for members of the group g1. ipa permission-add --attrs=telephonenumber --memberof=g1 --permissions=write g1_modify_members ipa privilege-add g1_junior_admin --desc='Group 1 junior admin' ipa privilege-add-permission --permissions=g1_modify_members g1_junior_admin ipa role-add --desc='Group 1 junior admin' group1 ipa role-add-privilege --privileges=g1_junior_admin group1 ipa role-add-member --users=g1a1 group1 So members of the group1 role can modify the telephonenumber attribute of its members. Let's see it in action: kinit g1a1 ipa user-mod --phone=410-555-1212 g1u1 -------------------- Modified user "g1u1" -------------------- User login: g1u1 First name: group1 Last name: user1 Home directory: /home/g1u1 Login shell: /bin/sh Email address: g1u1 at example.com UID: 1197000004 GID: 1197000004 Telephone Number: 410-555-1212 Account disabled: False Password: False Member of groups: ipausers, g1 Kerberos keys available: False Try another attribute and it fails as expected: ipa user-mod --fax=410-555-1212 g1u1 ipa: ERROR: Insufficient access: Insufficient 'write' privilege to the 'facsimileTelephoneNumber' attribute of entry 'uid=g1u1,cn=users,cn=accounts,dc=example,dc=com'. Change the phone number of a non-member of the group and it also fails as expected: ipa user-mod --phone=410-555-1213 g2u1 ipa: ERROR: Insufficient access: Insufficient 'write' privilege to the 'telephoneNumber' attribute of entry 'uid=g2u1,cn=users,cn=accounts,dc=example,dc=com'. rob From isaev at fintech.ru Fri Nov 8 16:11:03 2013 From: isaev at fintech.ru (=?utf-8?B?0JjRgdCw0LXQsiDQktC40YLQsNC70LjQuSDQkNC90LDRgtC+0LvRjNC10LI=?= =?utf-8?B?0LjRhw==?=) Date: Fri, 8 Nov 2013 16:11:03 +0000 Subject: [Freeipa-users] Access differentiation in group policy In-Reply-To: <527D0755.2030904@redhat.com> References: <69303615BE133645963548DD4A3BFCB3A610B9@E2K7.fintech.ru> <527D0755.2030904@redhat.com> Message-ID: <69303615BE133645963548DD4A3BFCB3A610FD@E2K7.fintech.ru> Rob, I apologize, just one more question. We dealt with the editing of attributes, but it is still not clear if it is possible to restrict the user adding to isolated group in case of the user's membership in other isolated group. -----Original Message----- From: Rob Crittenden [mailto:rcritten at redhat.com] Sent: Friday, November 08, 2013 7:47 PM To: ????? ??????? ???????????; freeipa-users at redhat.com Subject: Re: [Freeipa-users] Access differentiation in group policy ????? ??????? ??????????? wrote: > Dear colleagues, we faced with an issue of access differentiation for > junior IPA admins. Our idea was to create several (say, three ? > group1, group2, group3) isolated groups with one junior admin per group. > > The group isolation means that admin of group1 is not able to add to > his group neither users nor subgroups ? members of other global groups (i.e. > group2, group3) > > We have attempted to accomplish this by RBAC for every junior admin. > It was pointed out, that the admin can modify the objects (users, > subgroups) belonging to his group only. However, every user enrolled > to IPA can see all the other objects by default, therefore any junior > admin can add users and subgroups FROM THE OTHER isolated group to his > group with no restrictions. > > So the question is ? how to implement (the specified) group ?isolation? > in IPA? > > We?re running on the RHEL 6.4 with IPA 3.0. Thank you. You need to create some custom permissions that limit the capabilities by memberof. I set up a simple system with a couple of users: kinit admin ipa group-add --desc=g1 g1 ipa group-add --desc=g2 g2 ipa user-add --first=group1 --last=user1 g1u1 ipa user-add --first=group2 --last=user1 g2u1 ipa group-add-member --users g1u1 g1 ipa group-add-member --users g2u1 g2 ipa user-add --first=group1 --last=admin1 g1a1 ipa group-add-member --users g1a1 g1 ipa passwd g1a1 g1a1 is going to be my junior admin Next I created a permission so junior admins can manage the telephone number. This permission allows the phone number attribute to be written only for members of the group g1. ipa permission-add --attrs=telephonenumber --memberof=g1 --permissions=write g1_modify_members ipa privilege-add g1_junior_admin --desc='Group 1 junior admin' ipa privilege-add-permission --permissions=g1_modify_members g1_junior_admin ipa role-add --desc='Group 1 junior admin' group1 ipa role-add-privilege --privileges=g1_junior_admin group1 ipa role-add-member --users=g1a1 group1 So members of the group1 role can modify the telephonenumber attribute of its members. Let's see it in action: kinit g1a1 ipa user-mod --phone=410-555-1212 g1u1 -------------------- Modified user "g1u1" -------------------- User login: g1u1 First name: group1 Last name: user1 Home directory: /home/g1u1 Login shell: /bin/sh Email address: g1u1 at example.com UID: 1197000004 GID: 1197000004 Telephone Number: 410-555-1212 Account disabled: False Password: False Member of groups: ipausers, g1 Kerberos keys available: False Try another attribute and it fails as expected: ipa user-mod --fax=410-555-1212 g1u1 ipa: ERROR: Insufficient access: Insufficient 'write' privilege to the 'facsimileTelephoneNumber' attribute of entry 'uid=g1u1,cn=users,cn=accounts,dc=example,dc=com'. Change the phone number of a non-member of the group and it also fails as expected: ipa user-mod --phone=410-555-1213 g2u1 ipa: ERROR: Insufficient access: Insufficient 'write' privilege to the 'telephoneNumber' attribute of entry 'uid=g2u1,cn=users,cn=accounts,dc=example,dc=com'. rob From rcritten at redhat.com Fri Nov 8 16:47:09 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 08 Nov 2013 11:47:09 -0500 Subject: [Freeipa-users] Access differentiation in group policy In-Reply-To: <69303615BE133645963548DD4A3BFCB3A610FD@E2K7.fintech.ru> References: <69303615BE133645963548DD4A3BFCB3A610B9@E2K7.fintech.ru> <527D0755.2030904@redhat.com> <69303615BE133645963548DD4A3BFCB3A610FD@E2K7.fintech.ru> Message-ID: <527D158D.9030401@redhat.com> ????? ??????? ??????????? wrote: > Rob, I apologize, just one more question. We dealt with the editing of attributes, but it is still not clear if it is possible to restrict the user adding to isolated group in case of the user's membership in other isolated group. I'm not sure I follow. As you can see, this sort of access control can get very complex :-) Can you provide an example of what you want to do? rob > > -----Original Message----- > From: Rob Crittenden [mailto:rcritten at redhat.com] > Sent: Friday, November 08, 2013 7:47 PM > To: ????? ??????? ???????????; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Access differentiation in group policy > > ????? ??????? ??????????? wrote: >> Dear colleagues, we faced with an issue of access differentiation for >> junior IPA admins. Our idea was to create several (say, three ? >> group1, group2, group3) isolated groups with one junior admin per group. >> >> The group isolation means that admin of group1 is not able to add to >> his group neither users nor subgroups ? members of other global groups (i.e. >> group2, group3) >> >> We have attempted to accomplish this by RBAC for every junior admin. >> It was pointed out, that the admin can modify the objects (users, >> subgroups) belonging to his group only. However, every user enrolled >> to IPA can see all the other objects by default, therefore any junior >> admin can add users and subgroups FROM THE OTHER isolated group to his >> group with no restrictions. >> >> So the question is ? how to implement (the specified) group ?isolation? >> in IPA? >> >> We?re running on the RHEL 6.4 with IPA 3.0. Thank you. > > You need to create some custom permissions that limit the capabilities by memberof. > > I set up a simple system with a couple of users: > > kinit admin > ipa group-add --desc=g1 g1 > ipa group-add --desc=g2 g2 > ipa user-add --first=group1 --last=user1 g1u1 ipa user-add --first=group2 --last=user1 g2u1 ipa group-add-member --users g1u1 g1 ipa group-add-member --users g2u1 g2 ipa user-add --first=group1 --last=admin1 g1a1 ipa group-add-member --users g1a1 g1 ipa passwd g1a1 > > g1a1 is going to be my junior admin > > Next I created a permission so junior admins can manage the telephone number. This permission allows the phone number attribute to be written only for members of the group g1. > > ipa permission-add --attrs=telephonenumber --memberof=g1 --permissions=write g1_modify_members ipa privilege-add g1_junior_admin --desc='Group 1 junior admin' > ipa privilege-add-permission --permissions=g1_modify_members g1_junior_admin ipa role-add --desc='Group 1 junior admin' group1 ipa role-add-privilege --privileges=g1_junior_admin group1 ipa role-add-member --users=g1a1 group1 > > So members of the group1 role can modify the telephonenumber attribute of its members. > > Let's see it in action: > > kinit g1a1 > ipa user-mod --phone=410-555-1212 g1u1 > -------------------- > Modified user "g1u1" > -------------------- > User login: g1u1 > First name: group1 > Last name: user1 > Home directory: /home/g1u1 > Login shell: /bin/sh > Email address: g1u1 at example.com > UID: 1197000004 > GID: 1197000004 > Telephone Number: 410-555-1212 > Account disabled: False > Password: False > Member of groups: ipausers, g1 > Kerberos keys available: False > > Try another attribute and it fails as expected: > ipa user-mod --fax=410-555-1212 g1u1 > ipa: ERROR: Insufficient access: Insufficient 'write' privilege to the 'facsimileTelephoneNumber' attribute of entry 'uid=g1u1,cn=users,cn=accounts,dc=example,dc=com'. > > Change the phone number of a non-member of the group and it also fails as expected: > ipa user-mod --phone=410-555-1213 g2u1 > ipa: ERROR: Insufficient access: Insufficient 'write' privilege to the 'telephoneNumber' attribute of entry 'uid=g2u1,cn=users,cn=accounts,dc=example,dc=com'. > > rob > From deanhunter at comcast.net Fri Nov 8 20:42:21 2013 From: deanhunter at comcast.net (Dean Hunter) Date: Fri, 08 Nov 2013 14:42:21 -0600 Subject: [Freeipa-users] reboot required after ipa-client-install? In-Reply-To: <527C57D8.7090202@redhat.com> References: <1383797622.19912.34.camel@host.hunter.org> <20131107074421.GL25335@redhat.com> <1383844885.19912.43.camel@host.hunter.org> <527BCFAC.4080003@redhat.com> <1383847188.19912.44.camel@host.hunter.org> <527C171B.8010209@redhat.com> <1383866409.2467.6.camel@host.hunter.org> <527C57D8.7090202@redhat.com> Message-ID: <1383943341.2467.11.camel@host.hunter.org> On Thu, 2013-11-07 at 22:17 -0500, Dmitri Pal wrote: > On 11/07/2013 06:20 PM, Dean Hunter wrote: > > > On Thu, 2013-11-07 at 17:41 -0500, Dmitri Pal wrote: > > > > > On 11/07/2013 12:59 PM, Dean Hunter wrote: > > > > > > > On Thu, 2013-11-07 at 12:36 -0500, Dmitri Pal wrote: > > > > > > > > > On 11/07/2013 12:21 PM, Dean Hunter wrote: > > > > > > > > > > > On Thu, 2013-11-07 at 09:44 +0200, Alexander Bokovoy wrote: > > > > > > > > > > > > > On Wed, 06 Nov 2013, Dean Hunter wrote: > > > > > > > > > > > > > > >After building a new VM and configuring the IPA 3.3.2 client, Gnome > > > > > > > >seems to only perform a local log-in until the system is rebooted. SSH > > > > > > > >works with IPA, but not Gnome. Is this correct? Is there anything less > > > > > > > >disruptive than a reboot that I can do? > > > > > > > > > > > > > > > > > > > > > > > > > Restart gdm.service? > > > > > > > I'm not sure how gdm handles PAM auth. > > > > > > > > > > > > > > > > > > I have tried: > > > > > > > > > > > > ipa-client-install ... > > > > > > systemctl restart gdm.service > > > > > > > > > > > > but the behavior remains the same. The Gnome log in screen > > > > > > accepts the user name, pauses about 25 seconds, then > > > > > > displays the log in screen again without any messages or > > > > > > indication of a problem. This is the same behavior I see > > > > > > when entering an incorrect local user name before > > > > > > configuring IPA. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Freeipa-users mailing list > > > > > > Freeipa-users at redhat.com > > > > > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > > > > > > Can it be a DIR cache issue and the fact that the directory > > > > > can't is not created at proper time? > > > > > > > > > > > > Which directory, please? > > > > > > > > > If you are hitting the DIR cache issue (which I am not sure is the > > > case this is why I asked about AVCs) then the directory we are > > > talking about is /var/run/usr/ > > > This directory should be created by kerberos library when it tries > > > to authenticate a user. But it might not be able to since a parent > > > directory /var/run/usr might not be created yet. This is one of > > > the reasons why we decided not to continue the path of DIR cache > > > but switched to using Kernel based ccache. > > > > > > > > > > > > > > > > > > > > > > Do you see any AVCs? > > > > > > > > > Question still stands. > > > > > > I see no AVCs: > > > > [root at ipa ~]# ausearch --message AVC > > > > [root at ipa ~]# > > > > > > I did find this in the man page for nsswitch.conf: > > > > FILES > > A service named SERVICE is implemented by a shared > > object library named > > libnss_SERVICE.so.X that resides in /lib. > > > > /etc/nsswitch.conf NSS configuration file. > > /lib/libnss_compat.so.X implements "compat" > > source. > > /lib/libnss_db.so.X implements "db" source. > > /lib/libnss_dns.so.X implements "dns" source. > > /lib/libnss_files.so.X implements "files" > > source. > > /lib/libnss_hesiod.so.X implements "hesiod" > > source. > > /lib/libnss_nis.so.X implements "nis" source. > > /lib/libnss_nisplus.so.X implements "nisplus" > > source. > > > > NOTES > > Within each process that uses nsswitch.conf, the > > entire file is read > > only once. If the file is later changed, the > > process will continue > > using the old configuration. > > > > > > Is this why the default configuration of nsswitch.conf is changing > > in Fedora 20, as noted on of the preceeding e-mails? > > > > > > Yes I think SSS is now included by default. But if man page does not > list it it is probably a bug in the man page. Hmm, I just built a Fedora 20 Beta VM. /etc/nsswitch.conf is no different than after a Fedora 19 build. -------------- next part -------------- An HTML attachment was scrubbed... URL: From isaev at fintech.ru Mon Nov 11 07:17:00 2013 From: isaev at fintech.ru (=?utf-8?B?0JjRgdCw0LXQsiDQktC40YLQsNC70LjQuSDQkNC90LDRgtC+0LvRjNC10LI=?= =?utf-8?B?0LjRhw==?=) Date: Mon, 11 Nov 2013 07:17:00 +0000 Subject: [Freeipa-users] Access differentiation in group policy In-Reply-To: <527D158D.9030401@redhat.com> References: <69303615BE133645963548DD4A3BFCB3A610B9@E2K7.fintech.ru> <527D0755.2030904@redhat.com> <69303615BE133645963548DD4A3BFCB3A610FD@E2K7.fintech.ru> <527D158D.9030401@redhat.com> Message-ID: <69303615BE133645963548DD4A3BFCB3A61175@E2K7.fintech.ru> Here is our attempt to describe the problem in terms of IPA CLI commands: kinit admin ipa group-add --desc="Group 1" group1 ipa group-add --desc="Group 2" group2 ipa user-add --first="Admin" --last="Group 1" --password admin_group1 ipa user-add --first="Admin" --last="Group 2" --password admin_group2 ipa user-add --first="User" --last="Group 1" user_group1 ipa user-add --first="User" --last="Group 2" user_group2 ipa group-add-member --users=user_group1 group1 ipa group-add-member --users=admin_group1 group1 ipa group-add-member --users=user_group2 group2 ipa group-add-member --users=admin_group2 --password group2 ipa group-remove-member --users=user_group1,admin_group1,user_group2,admin_group2 ipausers ipa permission-add perm_edit_sn_group1 --permission=write --attrs=sn --memberof=group1 --type=user ipa permission-add perm_edit_member_group1 --permission=write --attrs=member --targetgroup=group1 ipa privilege-add priv_group1 --desc="Privilege Group1" ipa privilege-add-permission priv_group1 --permissions=perm_edit_sn_group1,perm_edit_member_group1 ipa role-add role_group1 --desc="Role Group1" ipa role-add-privilege role_group1 --privileges=priv_group1 ipa role-add-member role_group1 --users=admin_group1 kinit admin_group1 ipa user-mod user_group1 --last="Group 1" // I can't change user_group2's lastname. ipa user-mod user_group2 --last="Group 1" // But I can add to group1 any users or user groups existing in IPA. How can I disallow the admin_group1 to add users or user groups from other isolated groups? ipa group-add-member --users=user_group2 group1 // And now I can change user_group2's lastname. ipa user-mod user_group2 --last="Group 1" Thanks a lot. -----Original Message----- From: Rob Crittenden [mailto:rcritten at redhat.com] Sent: Friday, November 08, 2013 8:48 PM To: ????? ??????? ???????????; freeipa-users at redhat.com Subject: Re: [Freeipa-users] Access differentiation in group policy ????? ??????? ??????????? wrote: > Rob, I apologize, just one more question. We dealt with the editing of attributes, but it is still not clear if it is possible to restrict the user adding to isolated group in case of the user's membership in other isolated group. I'm not sure I follow. As you can see, this sort of access control can get very complex :-) Can you provide an example of what you want to do? rob > > -----Original Message----- > From: Rob Crittenden [mailto:rcritten at redhat.com] > Sent: Friday, November 08, 2013 7:47 PM > To: ????? ??????? ???????????; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Access differentiation in group policy > > ????? ??????? ??????????? wrote: >> Dear colleagues, we faced with an issue of access differentiation for >> junior IPA admins. Our idea was to create several (say, three ? >> group1, group2, group3) isolated groups with one junior admin per group. >> >> The group isolation means that admin of group1 is not able to add to >> his group neither users nor subgroups ? members of other global groups (i.e. >> group2, group3) >> >> We have attempted to accomplish this by RBAC for every junior admin. >> It was pointed out, that the admin can modify the objects (users, >> subgroups) belonging to his group only. However, every user enrolled >> to IPA can see all the other objects by default, therefore any junior >> admin can add users and subgroups FROM THE OTHER isolated group to >> his group with no restrictions. >> >> So the question is ? how to implement (the specified) group ?isolation? >> in IPA? >> >> We?re running on the RHEL 6.4 with IPA 3.0. Thank you. > > You need to create some custom permissions that limit the capabilities by memberof. > > I set up a simple system with a couple of users: > > kinit admin > ipa group-add --desc=g1 g1 > ipa group-add --desc=g2 g2 > ipa user-add --first=group1 --last=user1 g1u1 ipa user-add > --first=group2 --last=user1 g2u1 ipa group-add-member --users g1u1 g1 > ipa group-add-member --users g2u1 g2 ipa user-add --first=group1 > --last=admin1 g1a1 ipa group-add-member --users g1a1 g1 ipa passwd > g1a1 > > g1a1 is going to be my junior admin > > Next I created a permission so junior admins can manage the telephone number. This permission allows the phone number attribute to be written only for members of the group g1. > > ipa permission-add --attrs=telephonenumber --memberof=g1 --permissions=write g1_modify_members ipa privilege-add g1_junior_admin --desc='Group 1 junior admin' > ipa privilege-add-permission --permissions=g1_modify_members > g1_junior_admin ipa role-add --desc='Group 1 junior admin' group1 ipa > role-add-privilege --privileges=g1_junior_admin group1 ipa > role-add-member --users=g1a1 group1 > > So members of the group1 role can modify the telephonenumber attribute of its members. > > Let's see it in action: > > kinit g1a1 > ipa user-mod --phone=410-555-1212 g1u1 > -------------------- > Modified user "g1u1" > -------------------- > User login: g1u1 > First name: group1 > Last name: user1 > Home directory: /home/g1u1 > Login shell: /bin/sh > Email address: g1u1 at example.com > UID: 1197000004 > GID: 1197000004 > Telephone Number: 410-555-1212 > Account disabled: False > Password: False > Member of groups: ipausers, g1 > Kerberos keys available: False > > Try another attribute and it fails as expected: > ipa user-mod --fax=410-555-1212 g1u1 > ipa: ERROR: Insufficient access: Insufficient 'write' privilege to the 'facsimileTelephoneNumber' attribute of entry 'uid=g1u1,cn=users,cn=accounts,dc=example,dc=com'. > > Change the phone number of a non-member of the group and it also fails as expected: > ipa user-mod --phone=410-555-1213 g2u1 > ipa: ERROR: Insufficient access: Insufficient 'write' privilege to the 'telephoneNumber' attribute of entry 'uid=g2u1,cn=users,cn=accounts,dc=example,dc=com'. > > rob > From tompos at martos.bme.hu Mon Nov 11 08:27:45 2013 From: tompos at martos.bme.hu (Tamas Papp) Date: Mon, 11 Nov 2013 09:27:45 +0100 Subject: [Freeipa-users] sig11 Message-ID: <52809501.30003@martos.bme.hu> hi All, Nov 11 08:56:15 ipa31 kernel: [324701.614162] traps: ns-slapd[1333] general protection ip:7f438b682731 sp:7f43637fb9a8 error:0 in libc-2.17.so[7f438b5fc000+1b6000] Nov 11 08:56:15 ipa31 systemd[1]: dirsrv at CXN.service: main process exited, code=killed, status=11/SEGV Nov 11 08:56:15 ipa31 systemd[1]: Unit dirsrv at CXN.service entered failed state. We have two freeipa servers on Fedora 19. On one of them the service stopped. The above messages are from the messages log files. No I updated some packages by yum, but otherwise the system was uptodate: Installing: kernel x86_64 3.11.7-200.fc19 updates 30 M Updating: glibc x86_64 2.17-19.fc19 updates 3.6 M glibc-common x86_64 2.17-19.fc19 updates 11 M hwdata noarch 0.257-1.fc19 updates 1.1 M libdrm x86_64 2.4.47-1.fc19 updates 115 k libgcrypt x86_64 1.5.3-2.fc19 updates 256 k libipa_hbac x86_64 1.11.2-1.fc19 updates 60 k libipa_hbac-python x86_64 1.11.2-1.fc19 updates 54 k libsss_idmap x86_64 1.11.2-1.fc19 updates 64 k libsss_nss_idmap x86_64 1.11.2-1.fc19 updates 63 k mod_nss x86_64 1.0.8-24.fc19 updates 94 k openldap x86_64 2.4.36-4.fc19 updates 332 k openldap-clients x86_64 2.4.36-4.fc19 updates 182 k plymouth x86_64 0.8.9-0.2013.03.26.1.fc19 updates 104 k plymouth-core-libs x86_64 0.8.9-0.2013.03.26.1.fc19 updates 93 k plymouth-scripts x86_64 0.8.9-0.2013.03.26.1.fc19 updates 33 k python-sssdconfig noarch 1.11.2-1.fc19 updates 85 k python-urllib3 noarch 1.7-4.fc19 updates 60 k sssd x86_64 1.11.2-1.fc19 updates 54 k sssd-ad x86_64 1.11.2-1.fc19 updates 144 k sssd-client x86_64 1.11.2-1.fc19 updates 107 k sssd-common x86_64 1.11.2-1.fc19 updates 1.2 M sssd-common-pac x86_64 1.11.2-1.fc19 updates 109 k sssd-ipa x86_64 1.11.2-1.fc19 updates 251 k sssd-krb5 x86_64 1.11.2-1.fc19 updates 97 k sssd-krb5-common x86_64 1.11.2-1.fc19 updates 189 k sssd-ldap x86_64 1.11.2-1.fc19 updates 190 k sssd-proxy x86_64 1.11.2-1.fc19 updates 104 k tzdata noarch 2013h-1.fc19 updates 441 k tzdata-java noarch 2013h-1.fc19 updates 156 k Removing: kernel x86_64 3.9.5-301.fc19 @anaconda 124 M Any idea, what was the problem? Thanks, tamas From mkosek at redhat.com Mon Nov 11 08:30:48 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 11 Nov 2013 09:30:48 +0100 Subject: [Freeipa-users] ipa cli AttributeError: KerbTransport instance has no attribute '_conn' In-Reply-To: References: <527C17FC.8000301@redhat.com> <527CEB20.5090504@redhat.com> Message-ID: <528095B8.6090901@redhat.com> On 11/08/2013 03:00 PM, Jonathan Underwood wrote: > On 8 November 2013 13:46, Dmitri Pal wrote: >> On 11/08/2013 08:17 AM, Jonathan Underwood wrote: >>> Sooo.... I think that means the problem lies with apache and NSS, right? >> >> >> Or in the negotiated authentication. >> Is there anything in the kerberos logs on the server side? > > Nothing error wise. > >> Can you do an ldap connection using GSSAPI from the client? > > Yep. (Note the client machine in all my tests has actually been the > same machine as the server). > >> May be KDC is not accessible because FW does allow access to the KDC port? >> > > Nope, tisn't that, have stopped the iptables service, and also done a > setenforce 0. > >> Just some ideas what to check... >> > > OK, I am getting closer to diagnosing the problem. On the server > machine I had also configured apache to serve up another name based > vhost. Removing that vhost config and restarting httpd caused the ipa > ping command to work successfully. So, this seems to be a problem with > httpd/mod_nss and hosting IPA and other vhosts. Note the other vhost > wasn't using nss or ssl. I'll dig some more. Thanks Jonathan. If you get some results, you are very welcome to report back so that we can eventually file a bug, if it is really something that can be improved/fixed in FreeIPA side. Martin From abokovoy at redhat.com Mon Nov 11 08:37:53 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 11 Nov 2013 10:37:53 +0200 Subject: [Freeipa-users] sig11 In-Reply-To: <52809501.30003@martos.bme.hu> References: <52809501.30003@martos.bme.hu> Message-ID: <20131111083753.GA21264@redhat.com> On Mon, 11 Nov 2013, Tamas Papp wrote: >hi All, > >Nov 11 08:56:15 ipa31 kernel: [324701.614162] traps: ns-slapd[1333] >general protection ip:7f438b682731 sp:7f43637fb9a8 error:0 in >libc-2.17.so[7f438b5fc000+1b6000] >Nov 11 08:56:15 ipa31 systemd[1]: dirsrv at CXN.service: main process >exited, code=killed, status=11/SEGV >Nov 11 08:56:15 ipa31 systemd[1]: Unit dirsrv at CXN.service entered failed >state. > > >We have two freeipa servers on Fedora 19. On one of them the service >stopped. The above messages are from the messages log files. Please run # debuginfo-install 389-ds-base freeipa This would install debuginfo packages for the directory server and FreeIPA modules to it. Then try to restart ipa -- if crash would be reproducible, we should see full stacktrace in the journal. -- / Alexander Bokovoy From tompos at martos.bme.hu Mon Nov 11 08:41:41 2013 From: tompos at martos.bme.hu (Tamas Papp) Date: Mon, 11 Nov 2013 09:41:41 +0100 Subject: [Freeipa-users] sig11 In-Reply-To: <20131111083753.GA21264@redhat.com> References: <52809501.30003@martos.bme.hu> <20131111083753.GA21264@redhat.com> Message-ID: <52809845.1060404@martos.bme.hu> On 11/11/2013 09:37 AM, Alexander Bokovoy wrote: > On Mon, 11 Nov 2013, Tamas Papp wrote: >> hi All, >> >> Nov 11 08:56:15 ipa31 kernel: [324701.614162] traps: ns-slapd[1333] >> general protection ip:7f438b682731 sp:7f43637fb9a8 error:0 in >> libc-2.17.so[7f438b5fc000+1b6000] >> Nov 11 08:56:15 ipa31 systemd[1]: dirsrv at CXN.service: main process >> exited, code=killed, status=11/SEGV >> Nov 11 08:56:15 ipa31 systemd[1]: Unit dirsrv at CXN.service entered failed >> state. >> >> >> We have two freeipa servers on Fedora 19. On one of them the service >> stopped. The above messages are from the messages log files. > Please run > > # debuginfo-install 389-ds-base freeipa > > This would install debuginfo packages for the directory server and > FreeIPA modules to it. Then try to restart ipa -- if crash would be > reproducible, > we should see full stacktrace in the journal. OK. Let's see if it crashes again. If so, I'll do this. 10x tamas From mkosek at redhat.com Mon Nov 11 08:51:04 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 11 Nov 2013 09:51:04 +0100 Subject: [Freeipa-users] Access differentiation in group policy In-Reply-To: <69303615BE133645963548DD4A3BFCB3A61175@E2K7.fintech.ru> References: <69303615BE133645963548DD4A3BFCB3A610B9@E2K7.fintech.ru> <527D0755.2030904@redhat.com> <69303615BE133645963548DD4A3BFCB3A610FD@E2K7.fintech.ru> <527D158D.9030401@redhat.com> <69303615BE133645963548DD4A3BFCB3A61175@E2K7.fintech.ru> Message-ID: <52809A78.106@redhat.com> Normally, when you want to limit the groups that the membership can be applied to, one can use the targetfilter component of the relevant ACI. We did this for example for "Modify Group Membership" so that junior admins with this permission cannot add themselves to the main admins group: # ipa permission-show "Modify Group membership" Permission name: Modify Group membership Permissions: write Attributes: member Type: group Filter: (!(cn=admins)) Granted to Privilege: Modify Group membership, Group Administrators Indirect Member of roles: helpdesk, User Administrator # ipa permission-show "Modify Group membership" --raw aci: (targetattr = "member")(targetfilter = "(!(cn=admins))")(target = "ldap:///cn=*,cn=groups,cn=accounts,dc=example,dc=com")(version 3.0;acl "permission:Modify Group membership";allow (write) groupdn = "ldap:///cn=Modify Group membership,cn=permissions,cn=pbac,dc=example,dc=com";) Unfortunately, you cannot add the filter component to the permission using the CLI at the moment: # ipa permission-add perm_edit_member_group1 --permission=write --attrs=member --targetgroup=group1 --filter='(!(cn=admins))' ipa: ERROR: invalid 'target': type, filter, subtree and targetgroup are mutually exclusive This is a bug (https://fedorahosted.org/freeipa/ticket/2355), I speeded up it's resolution to next FreeIPA release. As for your current options, if you want to add both subtree and a filter, you can either manually edit the ACI itself via ldapmodify or update /usr/lib/python2.7/site-packages/ipalib/plugins/aci.py and remove "valid['filter']" part of the respective validation check and reload httpd. Martin On 11/11/2013 08:17 AM, ????? ??????? ??????????? wrote: > Here is our attempt to describe the problem in terms of IPA CLI commands: > > kinit admin > ipa group-add --desc="Group 1" group1 > ipa group-add --desc="Group 2" group2 > ipa user-add --first="Admin" --last="Group 1" --password admin_group1 > ipa user-add --first="Admin" --last="Group 2" --password admin_group2 > ipa user-add --first="User" --last="Group 1" user_group1 > ipa user-add --first="User" --last="Group 2" user_group2 > ipa group-add-member --users=user_group1 group1 > ipa group-add-member --users=admin_group1 group1 > ipa group-add-member --users=user_group2 group2 > ipa group-add-member --users=admin_group2 --password group2 > ipa group-remove-member --users=user_group1,admin_group1,user_group2,admin_group2 ipausers > ipa permission-add perm_edit_sn_group1 --permission=write --attrs=sn --memberof=group1 --type=user > ipa permission-add perm_edit_member_group1 --permission=write --attrs=member --targetgroup=group1 > ipa privilege-add priv_group1 --desc="Privilege Group1" > ipa privilege-add-permission priv_group1 --permissions=perm_edit_sn_group1,perm_edit_member_group1 > ipa role-add role_group1 --desc="Role Group1" > ipa role-add-privilege role_group1 --privileges=priv_group1 > ipa role-add-member role_group1 --users=admin_group1 > kinit admin_group1 > ipa user-mod user_group1 --last="Group 1" > // I can't change user_group2's lastname. > ipa user-mod user_group2 --last="Group 1" > // But I can add to group1 any users or user groups existing in IPA. How can I disallow the admin_group1 to add users or user groups from other isolated groups? > ipa group-add-member --users=user_group2 group1 > // And now I can change user_group2's lastname. > ipa user-mod user_group2 --last="Group 1" > > Thanks a lot. > > -----Original Message----- > From: Rob Crittenden [mailto:rcritten at redhat.com] > Sent: Friday, November 08, 2013 8:48 PM > To: ????? ??????? ???????????; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Access differentiation in group policy > > ????? ??????? ??????????? wrote: >> Rob, I apologize, just one more question. We dealt with the editing of attributes, but it is still not clear if it is possible to restrict the user adding to isolated group in case of the user's membership in other isolated group. > > I'm not sure I follow. As you can see, this sort of access control can get very complex :-) Can you provide an example of what you want to do? > > rob > >> >> -----Original Message----- >> From: Rob Crittenden [mailto:rcritten at redhat.com] >> Sent: Friday, November 08, 2013 7:47 PM >> To: ????? ??????? ???????????; freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] Access differentiation in group policy >> >> ????? ??????? ??????????? wrote: >>> Dear colleagues, we faced with an issue of access differentiation for >>> junior IPA admins. Our idea was to create several (say, three ? >>> group1, group2, group3) isolated groups with one junior admin per group. >>> >>> The group isolation means that admin of group1 is not able to add to >>> his group neither users nor subgroups ? members of other global groups (i.e. >>> group2, group3) >>> >>> We have attempted to accomplish this by RBAC for every junior admin. >>> It was pointed out, that the admin can modify the objects (users, >>> subgroups) belonging to his group only. However, every user enrolled >>> to IPA can see all the other objects by default, therefore any junior >>> admin can add users and subgroups FROM THE OTHER isolated group to >>> his group with no restrictions. >>> >>> So the question is ? how to implement (the specified) group ?isolation? >>> in IPA? >>> >>> We?re running on the RHEL 6.4 with IPA 3.0. Thank you. >> >> You need to create some custom permissions that limit the capabilities by memberof. >> >> I set up a simple system with a couple of users: >> >> kinit admin >> ipa group-add --desc=g1 g1 >> ipa group-add --desc=g2 g2 >> ipa user-add --first=group1 --last=user1 g1u1 ipa user-add >> --first=group2 --last=user1 g2u1 ipa group-add-member --users g1u1 g1 >> ipa group-add-member --users g2u1 g2 ipa user-add --first=group1 >> --last=admin1 g1a1 ipa group-add-member --users g1a1 g1 ipa passwd >> g1a1 >> >> g1a1 is going to be my junior admin >> >> Next I created a permission so junior admins can manage the telephone number. This permission allows the phone number attribute to be written only for members of the group g1. >> >> ipa permission-add --attrs=telephonenumber --memberof=g1 --permissions=write g1_modify_members ipa privilege-add g1_junior_admin --desc='Group 1 junior admin' >> ipa privilege-add-permission --permissions=g1_modify_members >> g1_junior_admin ipa role-add --desc='Group 1 junior admin' group1 ipa >> role-add-privilege --privileges=g1_junior_admin group1 ipa >> role-add-member --users=g1a1 group1 >> >> So members of the group1 role can modify the telephonenumber attribute of its members. >> >> Let's see it in action: >> >> kinit g1a1 >> ipa user-mod --phone=410-555-1212 g1u1 >> -------------------- >> Modified user "g1u1" >> -------------------- >> User login: g1u1 >> First name: group1 >> Last name: user1 >> Home directory: /home/g1u1 >> Login shell: /bin/sh >> Email address: g1u1 at example.com >> UID: 1197000004 >> GID: 1197000004 >> Telephone Number: 410-555-1212 >> Account disabled: False >> Password: False >> Member of groups: ipausers, g1 >> Kerberos keys available: False >> >> Try another attribute and it fails as expected: >> ipa user-mod --fax=410-555-1212 g1u1 >> ipa: ERROR: Insufficient access: Insufficient 'write' privilege to the 'facsimileTelephoneNumber' attribute of entry 'uid=g1u1,cn=users,cn=accounts,dc=example,dc=com'. >> >> Change the phone number of a non-member of the group and it also fails as expected: >> ipa user-mod --phone=410-555-1213 g2u1 >> ipa: ERROR: Insufficient access: Insufficient 'write' privilege to the 'telephoneNumber' attribute of entry 'uid=g2u1,cn=users,cn=accounts,dc=example,dc=com'. >> >> rob >> > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > From jhrozek at redhat.com Mon Nov 11 09:51:51 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 11 Nov 2013 10:51:51 +0100 Subject: [Freeipa-users] reboot required after ipa-client-install? In-Reply-To: <1383943341.2467.11.camel@host.hunter.org> References: <1383797622.19912.34.camel@host.hunter.org> <20131107074421.GL25335@redhat.com> <1383844885.19912.43.camel@host.hunter.org> <527BCFAC.4080003@redhat.com> <1383847188.19912.44.camel@host.hunter.org> <527C171B.8010209@redhat.com> <1383866409.2467.6.camel@host.hunter.org> <527C57D8.7090202@redhat.com> <1383943341.2467.11.camel@host.hunter.org> Message-ID: <20131111095151.GF4698@hendrix.brq.redhat.com> On Fri, Nov 08, 2013 at 02:42:21PM -0600, Dean Hunter wrote: > On Thu, 2013-11-07 at 22:17 -0500, Dmitri Pal wrote: > > > On 11/07/2013 06:20 PM, Dean Hunter wrote: > > > > > On Thu, 2013-11-07 at 17:41 -0500, Dmitri Pal wrote: > > > > > > > On 11/07/2013 12:59 PM, Dean Hunter wrote: > > > > > > > > > On Thu, 2013-11-07 at 12:36 -0500, Dmitri Pal wrote: > > > > > > > > > > > On 11/07/2013 12:21 PM, Dean Hunter wrote: > > > > > > > > > > > > > On Thu, 2013-11-07 at 09:44 +0200, Alexander Bokovoy wrote: > > > > > > > > > > > > > > > On Wed, 06 Nov 2013, Dean Hunter wrote: > > > > > > > > > > > > > > > > >After building a new VM and configuring the IPA 3.3.2 client, Gnome > > > > > > > > >seems to only perform a local log-in until the system is rebooted. SSH > > > > > > > > >works with IPA, but not Gnome. Is this correct? Is there anything less > > > > > > > > >disruptive than a reboot that I can do? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Restart gdm.service? > > > > > > > > I'm not sure how gdm handles PAM auth. > > > > > > > > > > > > > > > > > > > > > I have tried: > > > > > > > > > > > > > > ipa-client-install ... > > > > > > > systemctl restart gdm.service > > > > > > > > > > > > > > but the behavior remains the same. The Gnome log in screen > > > > > > > accepts the user name, pauses about 25 seconds, then > > > > > > > displays the log in screen again without any messages or > > > > > > > indication of a problem. This is the same behavior I see > > > > > > > when entering an incorrect local user name before > > > > > > > configuring IPA. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Freeipa-users mailing list > > > > > > > Freeipa-users at redhat.com > > > > > > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > > > > > > > > Can it be a DIR cache issue and the fact that the directory > > > > > > can't is not created at proper time? > > > > > > > > > > > > > > > Which directory, please? > > > > > > > > > > > > If you are hitting the DIR cache issue (which I am not sure is the > > > > case this is why I asked about AVCs) then the directory we are > > > > talking about is /var/run/usr/ > > > > This directory should be created by kerberos library when it tries > > > > to authenticate a user. But it might not be able to since a parent > > > > directory /var/run/usr might not be created yet. This is one of > > > > the reasons why we decided not to continue the path of DIR cache > > > > but switched to using Kernel based ccache. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Do you see any AVCs? > > > > > > > > > > > > Question still stands. > > > > > > > > > I see no AVCs: > > > > > > [root at ipa ~]# ausearch --message AVC > > > > > > [root at ipa ~]# > > > > > > > > > I did find this in the man page for nsswitch.conf: > > > > > > FILES > > > A service named SERVICE is implemented by a shared > > > object library named > > > libnss_SERVICE.so.X that resides in /lib. > > > > > > /etc/nsswitch.conf NSS configuration file. > > > /lib/libnss_compat.so.X implements "compat" > > > source. > > > /lib/libnss_db.so.X implements "db" source. > > > /lib/libnss_dns.so.X implements "dns" source. > > > /lib/libnss_files.so.X implements "files" > > > source. > > > /lib/libnss_hesiod.so.X implements "hesiod" > > > source. > > > /lib/libnss_nis.so.X implements "nis" source. > > > /lib/libnss_nisplus.so.X implements "nisplus" > > > source. > > > > > > NOTES > > > Within each process that uses nsswitch.conf, the > > > entire file is read > > > only once. If the file is later changed, the > > > process will continue > > > using the old configuration. > > > > > > > > > Is this why the default configuration of nsswitch.conf is changing > > > in Fedora 20, as noted on of the preceeding e-mails? > > > > > > > > > > > Yes I think SSS is now included by default. But if man page does not > > list it it is probably a bug in the man page. > > > Hmm, I just built a Fedora 20 Beta VM. /etc/nsswitch.conf is no > different than after a Fedora 19 build. That's weird, what is the glibc version? sss should be automatically added for quite some time, since https://bugzilla.redhat.com/show_bug.cgi?id=867473 was fixed.. From gflwqs at gmail.com Mon Nov 11 10:12:25 2013 From: gflwqs at gmail.com (gflwqs gflwqs) Date: Mon, 11 Nov 2013 11:12:25 +0100 Subject: [Freeipa-users] Winsync question Message-ID: Hi, I have configured my IPA server to do a UNI sync fromWindows. When i change some attribute on a synced user in IPA, for example the initials attribute, my understanding from the manuals is that when the next sync operation occurs my changes should be owerwritten? however it does not? can anyone clarify this behaviour? /Christian -------------- next part -------------- An HTML attachment was scrubbed... URL: From isaev at fintech.ru Mon Nov 11 10:28:44 2013 From: isaev at fintech.ru (=?utf-8?B?0JjRgdCw0LXQsiDQktC40YLQsNC70LjQuSDQkNC90LDRgtC+0LvRjNC10LI=?= =?utf-8?B?0LjRhw==?=) Date: Mon, 11 Nov 2013 10:28:44 +0000 Subject: [Freeipa-users] Access differentiation in group policy In-Reply-To: <52809A78.106@redhat.com> References: <69303615BE133645963548DD4A3BFCB3A610B9@E2K7.fintech.ru> <527D0755.2030904@redhat.com> <69303615BE133645963548DD4A3BFCB3A610FD@E2K7.fintech.ru> <527D158D.9030401@redhat.com> <69303615BE133645963548DD4A3BFCB3A61175@E2K7.fintech.ru> <52809A78.106@redhat.com> Message-ID: <69303615BE133645963548DD4A3BFCB3A611CD@E2K7.fintech.ru> Thanks a lot! We will try to work it out. -----Original Message----- From: Martin Kosek [mailto:mkosek at redhat.com] Sent: Monday, November 11, 2013 12:52 PM To: ????? ??????? ???????????; Rob Crittenden; freeipa-users at redhat.com Subject: Re: [Freeipa-users] Access differentiation in group policy Normally, when you want to limit the groups that the membership can be applied to, one can use the targetfilter component of the relevant ACI. We did this for example for "Modify Group Membership" so that junior admins with this permission cannot add themselves to the main admins group: # ipa permission-show "Modify Group membership" Permission name: Modify Group membership Permissions: write Attributes: member Type: group Filter: (!(cn=admins)) Granted to Privilege: Modify Group membership, Group Administrators Indirect Member of roles: helpdesk, User Administrator # ipa permission-show "Modify Group membership" --raw aci: (targetattr = "member")(targetfilter = "(!(cn=admins))")(target = "ldap:///cn=*,cn=groups,cn=accounts,dc=example,dc=com")(version 3.0;acl "permission:Modify Group membership";allow (write) groupdn = "ldap:///cn=Modify Group membership,cn=permissions,cn=pbac,dc=example,dc=com";) Unfortunately, you cannot add the filter component to the permission using the CLI at the moment: # ipa permission-add perm_edit_member_group1 --permission=write --attrs=member --targetgroup=group1 --filter='(!(cn=admins))' ipa: ERROR: invalid 'target': type, filter, subtree and targetgroup are mutually exclusive This is a bug (https://fedorahosted.org/freeipa/ticket/2355), I speeded up it's resolution to next FreeIPA release. As for your current options, if you want to add both subtree and a filter, you can either manually edit the ACI itself via ldapmodify or update /usr/lib/python2.7/site-packages/ipalib/plugins/aci.py and remove "valid['filter']" part of the respective validation check and reload httpd. Martin On 11/11/2013 08:17 AM, ????? ??????? ??????????? wrote: > Here is our attempt to describe the problem in terms of IPA CLI commands: > > kinit admin > ipa group-add --desc="Group 1" group1 > ipa group-add --desc="Group 2" group2 > ipa user-add --first="Admin" --last="Group 1" --password admin_group1 > ipa user-add --first="Admin" --last="Group 2" --password admin_group2 > ipa user-add --first="User" --last="Group 1" user_group1 ipa user-add > --first="User" --last="Group 2" user_group2 ipa group-add-member > --users=user_group1 group1 ipa group-add-member --users=admin_group1 > group1 ipa group-add-member --users=user_group2 group2 ipa > group-add-member --users=admin_group2 --password group2 ipa > group-remove-member > --users=user_group1,admin_group1,user_group2,admin_group2 ipausers ipa > permission-add perm_edit_sn_group1 --permission=write --attrs=sn > --memberof=group1 --type=user ipa permission-add perm_edit_member_group1 --permission=write --attrs=member --targetgroup=group1 ipa privilege-add priv_group1 --desc="Privilege Group1" > ipa privilege-add-permission priv_group1 > --permissions=perm_edit_sn_group1,perm_edit_member_group1 > ipa role-add role_group1 --desc="Role Group1" > ipa role-add-privilege role_group1 --privileges=priv_group1 ipa > role-add-member role_group1 --users=admin_group1 kinit admin_group1 > ipa user-mod user_group1 --last="Group 1" > // I can't change user_group2's lastname. > ipa user-mod user_group2 --last="Group 1" > // But I can add to group1 any users or user groups existing in IPA. How can I disallow the admin_group1 to add users or user groups from other isolated groups? > ipa group-add-member --users=user_group2 group1 // And now I can > change user_group2's lastname. > ipa user-mod user_group2 --last="Group 1" > > Thanks a lot. > > -----Original Message----- > From: Rob Crittenden [mailto:rcritten at redhat.com] > Sent: Friday, November 08, 2013 8:48 PM > To: ????? ??????? ???????????; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Access differentiation in group policy > > ????? ??????? ??????????? wrote: >> Rob, I apologize, just one more question. We dealt with the editing of attributes, but it is still not clear if it is possible to restrict the user adding to isolated group in case of the user's membership in other isolated group. > > I'm not sure I follow. As you can see, this sort of access control can get very complex :-) Can you provide an example of what you want to do? > > rob > >> >> -----Original Message----- >> From: Rob Crittenden [mailto:rcritten at redhat.com] >> Sent: Friday, November 08, 2013 7:47 PM >> To: ????? ??????? ???????????; freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] Access differentiation in group policy >> >> ????? ??????? ??????????? wrote: >>> Dear colleagues, we faced with an issue of access differentiation >>> for junior IPA admins. Our idea was to create several (say, three ? >>> group1, group2, group3) isolated groups with one junior admin per group. >>> >>> The group isolation means that admin of group1 is not able to add to >>> his group neither users nor subgroups ? members of other global groups (i.e. >>> group2, group3) >>> >>> We have attempted to accomplish this by RBAC for every junior admin. >>> It was pointed out, that the admin can modify the objects (users, >>> subgroups) belonging to his group only. However, every user >>> enrolled to IPA can see all the other objects by default, therefore >>> any junior admin can add users and subgroups FROM THE OTHER isolated >>> group to his group with no restrictions. >>> >>> So the question is ? how to implement (the specified) group ?isolation? >>> in IPA? >>> >>> We?re running on the RHEL 6.4 with IPA 3.0. Thank you. >> >> You need to create some custom permissions that limit the capabilities by memberof. >> >> I set up a simple system with a couple of users: >> >> kinit admin >> ipa group-add --desc=g1 g1 >> ipa group-add --desc=g2 g2 >> ipa user-add --first=group1 --last=user1 g1u1 ipa user-add >> --first=group2 --last=user1 g2u1 ipa group-add-member --users g1u1 g1 >> ipa group-add-member --users g2u1 g2 ipa user-add --first=group1 >> --last=admin1 g1a1 ipa group-add-member --users g1a1 g1 ipa passwd >> g1a1 >> >> g1a1 is going to be my junior admin >> >> Next I created a permission so junior admins can manage the telephone number. This permission allows the phone number attribute to be written only for members of the group g1. >> >> ipa permission-add --attrs=telephonenumber --memberof=g1 --permissions=write g1_modify_members ipa privilege-add g1_junior_admin --desc='Group 1 junior admin' >> ipa privilege-add-permission --permissions=g1_modify_members >> g1_junior_admin ipa role-add --desc='Group 1 junior admin' group1 ipa >> role-add-privilege --privileges=g1_junior_admin group1 ipa >> role-add-member --users=g1a1 group1 >> >> So members of the group1 role can modify the telephonenumber attribute of its members. >> >> Let's see it in action: >> >> kinit g1a1 >> ipa user-mod --phone=410-555-1212 g1u1 >> -------------------- >> Modified user "g1u1" >> -------------------- >> User login: g1u1 >> First name: group1 >> Last name: user1 >> Home directory: /home/g1u1 >> Login shell: /bin/sh >> Email address: g1u1 at example.com >> UID: 1197000004 >> GID: 1197000004 >> Telephone Number: 410-555-1212 >> Account disabled: False >> Password: False >> Member of groups: ipausers, g1 >> Kerberos keys available: False >> >> Try another attribute and it fails as expected: >> ipa user-mod --fax=410-555-1212 g1u1 >> ipa: ERROR: Insufficient access: Insufficient 'write' privilege to the 'facsimileTelephoneNumber' attribute of entry 'uid=g1u1,cn=users,cn=accounts,dc=example,dc=com'. >> >> Change the phone number of a non-member of the group and it also fails as expected: >> ipa user-mod --phone=410-555-1213 g2u1 >> ipa: ERROR: Insufficient access: Insufficient 'write' privilege to the 'telephoneNumber' attribute of entry 'uid=g2u1,cn=users,cn=accounts,dc=example,dc=com'. >> >> rob >> > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > From sramling at redhat.com Mon Nov 11 10:32:01 2013 From: sramling at redhat.com (Sankar Ramlingam) Date: Mon, 11 Nov 2013 16:02:01 +0530 Subject: [Freeipa-users] Winsync question In-Reply-To: References: Message-ID: <5280B221.3070900@redhat.com> On 11/11/2013 03:42 PM, gflwqs gflwqs wrote: > Hi, > I have configured my IPA server to do a UNI sync fromWindows. > When i change some attribute on a synced user in IPA, for example the > initials attribute, my understanding from the manuals is that when the > next sync operation occurs my changes should be owerwritten? It doesn't happen unless you make changes for the same user/attribute on AD or re-initialization. > however it does not? can anyone clarify this behaviour? > > /Christian > > > _______________________________________________ > 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 nicklas.bjork at skalarit.se Mon Nov 11 13:25:45 2013 From: nicklas.bjork at skalarit.se (=?UTF-8?B?Tmlja2xhcyBCasO2cms=?=) Date: Mon, 11 Nov 2013 14:25:45 +0100 Subject: [Freeipa-users] Generating SIDs for old user accounts on FreeIPA 3.0 Message-ID: <5280DAD9.9010405@skalarit.se> Hi list, We are running FreeIPA 3.0 with an installation that has been with us since the 2.x-era. We had a situation where we needed the NT password hash, which wasn't generated in earlier versions of FreeIPA, and would not be available for old user accounts even on this newer version. New user accounts would get them set upon creation. On #freeipa at FreeNode, ab was kind enough to guide me through the process of starting an ldap-task to add the needed attributes to the old accounts. I thought I'd share this in case anyone else would ask the same question. The procedure is also described on slide 11 in this presentation http://www.freeipa.org/images/4/49/Freeipa30_Trust_Basics.odp?. 1) Make sure you have /usr/lib{,64}/dirsrv/plugins/libipa_sidgen.so and /usr/lib{,64}/dirsrv/plugins/libipa_sidgen_task.so on your system. 2) Copy /usr/share/ipa/ipa-sidgen-task-run.ldif, edit nsslapd-basedn to match your base dn. (grep basedn /etc/ipa/default.conf | cut -d= -f2-) 3) ldapadd the ldif to cn=config, to start the task. I am not sure under which circumstances when the NT hash is automagically updated, but setting a new user password did update all password fields. Best regards, Nicklas Bj?rk From rmeggins at redhat.com Mon Nov 11 14:44:12 2013 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 11 Nov 2013 07:44:12 -0700 Subject: [Freeipa-users] sig11 In-Reply-To: <52809845.1060404@martos.bme.hu> References: <52809501.30003@martos.bme.hu> <20131111083753.GA21264@redhat.com> <52809845.1060404@martos.bme.hu> Message-ID: <5280ED3C.8040203@redhat.com> On 11/11/2013 01:41 AM, Tamas Papp wrote: > On 11/11/2013 09:37 AM, Alexander Bokovoy wrote: >> On Mon, 11 Nov 2013, Tamas Papp wrote: >>> hi All, >>> >>> Nov 11 08:56:15 ipa31 kernel: [324701.614162] traps: ns-slapd[1333] >>> general protection ip:7f438b682731 sp:7f43637fb9a8 error:0 in >>> libc-2.17.so[7f438b5fc000+1b6000] >>> Nov 11 08:56:15 ipa31 systemd[1]: dirsrv at CXN.service: main process >>> exited, code=killed, status=11/SEGV >>> Nov 11 08:56:15 ipa31 systemd[1]: Unit dirsrv at CXN.service entered failed >>> state. >>> >>> >>> We have two freeipa servers on Fedora 19. On one of them the service >>> stopped. The above messages are from the messages log files. >> Please run >> >> # debuginfo-install 389-ds-base freeipa >> >> This would install debuginfo packages for the directory server and >> FreeIPA modules to it. Then try to restart ipa -- if crash would be >> reproducible, >> we should see full stacktrace in the journal. > OK. Let's see if it crashes again. If so, I'll do this. See also http://port389.org/wiki/FAQ#Debugging_Crashes There is more to do than just install debuginfo packages . . . > > 10x > tamas > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From gflwqs at gmail.com Mon Nov 11 15:42:55 2013 From: gflwqs at gmail.com (gflwqs gflwqs) Date: Mon, 11 Nov 2013 16:42:55 +0100 Subject: [Freeipa-users] passync questions? Message-ID: Hi, I have setup the winsync and passsync service according to the docs, but having problems with passsync. Scenario: When i change password in IPA which does not meet the password policy defined in AD the password does not get synced over to AD, however it get set on the IPA side? Question: Should'nt the password change be rejected on the IPA side? /Christian -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Mon Nov 11 16:16:50 2013 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 11 Nov 2013 09:16:50 -0700 Subject: [Freeipa-users] passync questions? In-Reply-To: References: Message-ID: <528102F2.6010009@redhat.com> On 11/11/2013 08:42 AM, gflwqs gflwqs wrote: > Hi, > I have setup the winsync and passsync service according to the docs, > but having problems with passsync. > > Scenario: > When i change password in IPA which does not meet the password policy > defined in AD the password does not get synced over to AD, however it > get set on the IPA side? > > Question: Should'nt the password change be rejected on the IPA side? Set the same password policies in IPA that you have set in AD. Password policy settings are not synchronized between IPA and AD. > > /Christian > > > _______________________________________________ > 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 deanhunter at comcast.net Mon Nov 11 18:50:58 2013 From: deanhunter at comcast.net (Dean Hunter) Date: Mon, 11 Nov 2013 12:50:58 -0600 Subject: [Freeipa-users] reboot required after ipa-client-install? In-Reply-To: <20131111095151.GF4698@hendrix.brq.redhat.com> References: <1383797622.19912.34.camel@host.hunter.org> <20131107074421.GL25335@redhat.com> <1383844885.19912.43.camel@host.hunter.org> <527BCFAC.4080003@redhat.com> <1383847188.19912.44.camel@host.hunter.org> <527C171B.8010209@redhat.com> <1383866409.2467.6.camel@host.hunter.org> <527C57D8.7090202@redhat.com> <1383943341.2467.11.camel@host.hunter.org> <20131111095151.GF4698@hendrix.brq.redhat.com> Message-ID: <1384195858.2513.4.camel@host.hunter.org> On Mon, 2013-11-11 at 10:51 +0100, Jakub Hrozek wrote: > On Fri, Nov 08, 2013 at 02:42:21PM -0600, Dean Hunter wrote: > > On Thu, 2013-11-07 at 22:17 -0500, Dmitri Pal wrote: > > > > > On 11/07/2013 06:20 PM, Dean Hunter wrote: > > > > > > > On Thu, 2013-11-07 at 17:41 -0500, Dmitri Pal wrote: > > > > > > > > > On 11/07/2013 12:59 PM, Dean Hunter wrote: > > > > > > > > > > > On Thu, 2013-11-07 at 12:36 -0500, Dmitri Pal wrote: > > > > > > > > > > > > > On 11/07/2013 12:21 PM, Dean Hunter wrote: > > > > > > > > > > > > > > > On Thu, 2013-11-07 at 09:44 +0200, Alexander Bokovoy wrote: > > > > > > > > > > > > > > > > > On Wed, 06 Nov 2013, Dean Hunter wrote: > > > > > > > > > > > > > > > > > > >After building a new VM and configuring the IPA 3.3.2 client, Gnome > > > > > > > > > >seems to only perform a local log-in until the system is rebooted. SSH > > > > > > > > > >works with IPA, but not Gnome. Is this correct? Is there anything less > > > > > > > > > >disruptive than a reboot that I can do? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Restart gdm.service? > > > > > > > > > I'm not sure how gdm handles PAM auth. > > > > > > > > > > > > > > > > > > > > > > > > I have tried: > > > > > > > > > > > > > > > > ipa-client-install ... > > > > > > > > systemctl restart gdm.service > > > > > > > > > > > > > > > > but the behavior remains the same. The Gnome log in screen > > > > > > > > accepts the user name, pauses about 25 seconds, then > > > > > > > > displays the log in screen again without any messages or > > > > > > > > indication of a problem. This is the same behavior I see > > > > > > > > when entering an incorrect local user name before > > > > > > > > configuring IPA. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Freeipa-users mailing list > > > > > > > > Freeipa-users at redhat.com > > > > > > > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > > > > > > > > > > Can it be a DIR cache issue and the fact that the directory > > > > > > > can't is not created at proper time? > > > > > > > > > > > > > > > > > > Which directory, please? > > > > > > > > > > > > > > > If you are hitting the DIR cache issue (which I am not sure is the > > > > > case this is why I asked about AVCs) then the directory we are > > > > > talking about is /var/run/usr/ > > > > > This directory should be created by kerberos library when it tries > > > > > to authenticate a user. But it might not be able to since a parent > > > > > directory /var/run/usr might not be created yet. This is one of > > > > > the reasons why we decided not to continue the path of DIR cache > > > > > but switched to using Kernel based ccache. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Do you see any AVCs? > > > > > > > > > > > > > > > Question still stands. > > > > > > > > > > > > I see no AVCs: > > > > > > > > [root at ipa ~]# ausearch --message AVC > > > > > > > > [root at ipa ~]# > > > > > > > > > > > > I did find this in the man page for nsswitch.conf: > > > > > > > > FILES > > > > A service named SERVICE is implemented by a shared > > > > object library named > > > > libnss_SERVICE.so.X that resides in /lib. > > > > > > > > /etc/nsswitch.conf NSS configuration file. > > > > /lib/libnss_compat.so.X implements "compat" > > > > source. > > > > /lib/libnss_db.so.X implements "db" source. > > > > /lib/libnss_dns.so.X implements "dns" source. > > > > /lib/libnss_files.so.X implements "files" > > > > source. > > > > /lib/libnss_hesiod.so.X implements "hesiod" > > > > source. > > > > /lib/libnss_nis.so.X implements "nis" source. > > > > /lib/libnss_nisplus.so.X implements "nisplus" > > > > source. > > > > > > > > NOTES > > > > Within each process that uses nsswitch.conf, the > > > > entire file is read > > > > only once. If the file is later changed, the > > > > process will continue > > > > using the old configuration. > > > > > > > > > > > > Is this why the default configuration of nsswitch.conf is changing > > > > in Fedora 20, as noted on of the preceeding e-mails? > > > > > > > > > > > > > > > > Yes I think SSS is now included by default. But if man page does not > > > list it it is probably a bug in the man page. > > > > > > Hmm, I just built a Fedora 20 Beta VM. /etc/nsswitch.conf is no > > different than after a Fedora 19 build. > > That's weird, what is the glibc version? sss should be automatically > added for quite some time, since > https://bugzilla.redhat.com/show_bug.cgi?id=867473 was fixed.. [root at test ~]# rpm -q glibc glibc-2.18-11.fc20.x86_64 [root at test ~]# https://bugzilla.redhat.com/show_bug.cgi?id=867473 indicates the problem was fixed in Fedora 18. But the problem still occurs for both Fedora 19 and Fedora 20. Should I reopen the bug report? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Mon Nov 11 18:57:28 2013 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 11 Nov 2013 13:57:28 -0500 Subject: [Freeipa-users] reboot required after ipa-client-install? In-Reply-To: <1384195858.2513.4.camel@host.hunter.org> References: <1383797622.19912.34.camel@host.hunter.org> <20131107074421.GL25335@redhat.com> <1383844885.19912.43.camel@host.hunter.org> <527BCFAC.4080003@redhat.com> <1383847188.19912.44.camel@host.hunter.org> <527C171B.8010209@redhat.com> <1383866409.2467.6.camel@host.hunter.org> <527C57D8.7090202@redhat.com> <1383943341.2467.11.camel@host.hunter.org> <20131111095151.GF4698@hendrix.brq.redhat.com> <1384195858.2513.4.camel@host.hunter.org> Message-ID: <52812898.1040907@redhat.com> On 11/11/2013 01:50 PM, Dean Hunter wrote: > > [root at test ~]# rpm -q glibc > glibc-2.18-11.fc20.x86_64 > [root at test ~]# > > https://bugzilla.redhat.com/show_bug.cgi?id=867473 indicates the > problem was fixed in Fedora 18. But the problem still occurs for both > Fedora 19 and Fedora 20. Should I reopen the bug report? > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users Yes please. -- 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 deanhunter at comcast.net Mon Nov 11 19:07:11 2013 From: deanhunter at comcast.net (Dean Hunter) Date: Mon, 11 Nov 2013 13:07:11 -0600 Subject: [Freeipa-users] reboot required after ipa-client-install? In-Reply-To: <52812898.1040907@redhat.com> References: <1383797622.19912.34.camel@host.hunter.org> <20131107074421.GL25335@redhat.com> <1383844885.19912.43.camel@host.hunter.org> <527BCFAC.4080003@redhat.com> <1383847188.19912.44.camel@host.hunter.org> <527C171B.8010209@redhat.com> <1383866409.2467.6.camel@host.hunter.org> <527C57D8.7090202@redhat.com> <1383943341.2467.11.camel@host.hunter.org> <20131111095151.GF4698@hendrix.brq.redhat.com> <1384195858.2513.4.camel@host.hunter.org> <52812898.1040907@redhat.com> Message-ID: <1384196831.2513.6.camel@host.hunter.org> On Mon, 2013-11-11 at 13:57 -0500, Dmitri Pal wrote: > On 11/11/2013 01:50 PM, Dean Hunter wrote: > > > > > [root at test ~]# rpm -q glibc > > glibc-2.18-11.fc20.x86_64 > > [root at test ~]# > > > > https://bugzilla.redhat.com/show_bug.cgi?id=867473 indicates the > > problem was fixed in Fedora 18. But the problem still occurs for > > both Fedora 19 and Fedora 20. Should I reopen the bug report? > Yes please. I am sorry, but I do not seem to have permission to re-open this bug report. -------------- next part -------------- An HTML attachment was scrubbed... URL: From stbenjam at redhat.com Mon Nov 11 22:14:47 2013 From: stbenjam at redhat.com (Stephen Benjamin) Date: Mon, 11 Nov 2013 17:14:47 -0500 (EST) Subject: [Freeipa-users] "Remove Host" Permission Not Working In-Reply-To: <235038297.20670356.1384207824587.JavaMail.root@redhat.com> Message-ID: <1974868340.20671799.1384208087542.JavaMail.root@redhat.com> Hi, I've been working on getting Foreman and my FreeIPA instance completely integrated: https://bitbin.de/blog/2013/11/foreman-freeipa-integration-guide/ But I have an issue, I have a user that has limited roles for Host Enrollment, including "Add Host" and "Remove Host" permissions. Remove Host doesn't work like I expect: $ ipa host-del testbuild.bitbin.de ipa: ERROR: Insufficient access: not allowed to perform this command Failed while deleting host from IPA. Logs: [Mon Nov 11 23:03:35 2013] [error] ipa: INFO: registration at BITBIN.DE: host_del((u'testbuild.bitbin.de',), updatedns=False): ACIError Is there an additional permission I need? I tried a bunch of different permissions but I couldn't figure out the right one to give. Thanks, Stephen From deanhunter at comcast.net Mon Nov 11 22:21:18 2013 From: deanhunter at comcast.net (Dean Hunter) Date: Mon, 11 Nov 2013 16:21:18 -0600 Subject: [Freeipa-users] reboot required after ipa-client-install? In-Reply-To: <1384196831.2513.6.camel@host.hunter.org> References: <1383797622.19912.34.camel@host.hunter.org> <20131107074421.GL25335@redhat.com> <1383844885.19912.43.camel@host.hunter.org> <527BCFAC.4080003@redhat.com> <1383847188.19912.44.camel@host.hunter.org> <527C171B.8010209@redhat.com> <1383866409.2467.6.camel@host.hunter.org> <527C57D8.7090202@redhat.com> <1383943341.2467.11.camel@host.hunter.org> <20131111095151.GF4698@hendrix.brq.redhat.com> <1384195858.2513.4.camel@host.hunter.org> <52812898.1040907@redhat.com> <1384196831.2513.6.camel@host.hunter.org> Message-ID: <1384208478.2513.14.camel@host.hunter.org> On Mon, 2013-11-11 at 13:07 -0600, Dean Hunter wrote: > On Mon, 2013-11-11 at 13:57 -0500, Dmitri Pal wrote: > > > On 11/11/2013 01:50 PM, Dean Hunter wrote: > > > > > > > > [root at test ~]# rpm -q glibc > > > glibc-2.18-11.fc20.x86_64 > > > [root at test ~]# > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=867473 indicates the > > > problem was fixed in Fedora 18. But the problem still occurs for > > > both Fedora 19 and Fedora 20. Should I reopen the bug report? > > > > > Yes please. > > > I am sorry, but I do not seem to have permission to re-open this bug > report. It appears to me as if https://bugzilla.redhat.com/show_bug.cgi?id=980861 describes the source of the problem. authconfig is being run by Anaconda(?) overwriting the initial values of the /etc/nsswitch.conf file. Anaconda needs to specify different options when invoking authconfig. Adding "--enablesssd" to the authconfig statement in the Kickstart file for Fedora 19 and 20 seems to produce the desired result. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Mon Nov 11 23:22:47 2013 From: simo at redhat.com (Simo Sorce) Date: Mon, 11 Nov 2013 18:22:47 -0500 Subject: [Freeipa-users] reboot required after ipa-client-install? In-Reply-To: <1384208478.2513.14.camel@host.hunter.org> References: <1383797622.19912.34.camel@host.hunter.org> <20131107074421.GL25335@redhat.com> <1383844885.19912.43.camel@host.hunter.org> <527BCFAC.4080003@redhat.com> <1383847188.19912.44.camel@host.hunter.org> <527C171B.8010209@redhat.com> <1383866409.2467.6.camel@host.hunter.org> <527C57D8.7090202@redhat.com> <1383943341.2467.11.camel@host.hunter.org> <20131111095151.GF4698@hendrix.brq.redhat.com> <1384195858.2513.4.camel@host.hunter.org> <52812898.1040907@redhat.com> <1384196831.2513.6.camel@host.hunter.org> <1384208478.2513.14.camel@host.hunter.org> Message-ID: <1384212167.9191.108.camel@willson.li.ssimo.org> On Mon, 2013-11-11 at 16:21 -0600, Dean Hunter wrote: > On Mon, 2013-11-11 at 13:07 -0600, Dean Hunter wrote: > > On Mon, 2013-11-11 at 13:57 -0500, Dmitri Pal wrote: > > > On 11/11/2013 01:50 PM, Dean Hunter wrote: > > > > > > > > [root at test ~]# rpm -q glibc > > > > glibc-2.18-11.fc20.x86_64 > > > > [root at test ~]# > > > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=867473 indicates the > > > > problem was fixed in Fedora 18. But the problem still occurs for > > > > both Fedora 19 and Fedora 20. Should I reopen the bug report? > > > > > Yes please. > > > > I am sorry, but I do not seem to have permission to re-open this bug > > report. > > It appears to me as if > https://bugzilla.redhat.com/show_bug.cgi?id=980861 describes the > source of the problem. authconfig is being run by Anaconda(?) > overwriting the initial values of the /etc/nsswitch.conf file. > Anaconda needs to specify different options when invoking authconfig. > Adding "--enablesssd" to the authconfig statement in the Kickstart > file for Fedora 19 and 20 seems to produce the desired result. Thanks for the analysis Dean, however I would say it is a bug in authconfig. Authconfig should not removed the sss lines by default. Simo. -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Tue Nov 12 01:26:14 2013 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 11 Nov 2013 20:26:14 -0500 Subject: [Freeipa-users] reboot required after ipa-client-install? In-Reply-To: <1384212167.9191.108.camel@willson.li.ssimo.org> References: <1383797622.19912.34.camel@host.hunter.org> <20131107074421.GL25335@redhat.com> <1383844885.19912.43.camel@host.hunter.org> <527BCFAC.4080003@redhat.com> <1383847188.19912.44.camel@host.hunter.org> <527C171B.8010209@redhat.com> <1383866409.2467.6.camel@host.hunter.org> <527C57D8.7090202@redhat.com> <1383943341.2467.11.camel@host.hunter.org> <20131111095151.GF4698@hendrix.brq.redhat.com> <1384195858.2513.4.camel@host.hunter.org> <52812898.1040907@redhat.com> <1384196831.2513.6.camel@host.hunter.org> <1384208478.2513.14.camel@host.hunter.org> <1384212167.9191.108.camel@willson.li.ssimo.org> Message-ID: <528183B6.8000402@redhat.com> On 11/11/2013 06:22 PM, Simo Sorce wrote: > On Mon, 2013-11-11 at 16:21 -0600, Dean Hunter wrote: >> On Mon, 2013-11-11 at 13:07 -0600, Dean Hunter wrote: >>> On Mon, 2013-11-11 at 13:57 -0500, Dmitri Pal wrote: >>>> On 11/11/2013 01:50 PM, Dean Hunter wrote: >>>>> [root at test ~]# rpm -q glibc >>>>> glibc-2.18-11.fc20.x86_64 >>>>> [root at test ~]# >>>>> >>>>> https://bugzilla.redhat.com/show_bug.cgi?id=867473 indicates the >>>>> problem was fixed in Fedora 18. But the problem still occurs for >>>>> both Fedora 19 and Fedora 20. Should I reopen the bug report? >>>> Yes please. >>> I am sorry, but I do not seem to have permission to re-open this bug >>> report. >> It appears to me as if >> https://bugzilla.redhat.com/show_bug.cgi?id=980861 describes the >> source of the problem. authconfig is being run by Anaconda(?) >> overwriting the initial values of the /etc/nsswitch.conf file. >> Anaconda needs to specify different options when invoking authconfig. >> Adding "--enablesssd" to the authconfig statement in the Kickstart >> file for Fedora 19 and 20 seems to produce the desired result. > Thanks for the analysis Dean, however I would say it is a bug in > authconfig. > Authconfig should not removed the sss lines by default. > > Simo. > May be it grants a new bug then. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From jpazdziora at redhat.com Tue Nov 12 01:49:06 2013 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Tue, 12 Nov 2013 09:49:06 +0800 Subject: [Freeipa-users] Starting with host based access control and your existing users and hosts Message-ID: <20131112014906.GA4795@redhat.com> In FreeIPA installations that already have some users and hosts in them, the setup might be using host based access control (HBAC) without admins realizing it because by default there is a catchall allow_all rule there. When you then want to start tweaking the setup, the allow_all rule needs to be disabled or it would still allow all accesses. That might break existing users. Check http://www.freeipa.org/page/Howto/HBAC_and_allow_all about possible solution to that problem. -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat From gflwqs at gmail.com Tue Nov 12 08:29:42 2013 From: gflwqs at gmail.com (gflwqs gflwqs) Date: Tue, 12 Nov 2013 09:29:42 +0100 Subject: [Freeipa-users] Active Directory Sync user rights? Message-ID: Hi, I have created the sync user with: - *Replicating directory changes* rights to the synchronized Active Directory subtree. - A member of the *Account Operator* and *Enterprise Read-Only Domain controller* groups. The user attribute syncronization is working fine, however the passync from IPA to AD does not work, i get this error message when i change a password for a user from IPA: (00000005: SecErr: DSID-031A121F, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0 ) for modify operation If i add the sync user to the Domain Admins group it works, however according to the docs this should not be necessary? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Tue Nov 12 08:57:04 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 12 Nov 2013 09:57:04 +0100 Subject: [Freeipa-users] "Remove Host" Permission Not Working In-Reply-To: <1974868340.20671799.1384208087542.JavaMail.root@redhat.com> References: <1974868340.20671799.1384208087542.JavaMail.root@redhat.com> Message-ID: <5281ED60.4010206@redhat.com> On 11/11/2013 11:14 PM, Stephen Benjamin wrote: > Hi, > > I've been working on getting Foreman and my FreeIPA instance completely integrated: > > https://bitbin.de/blog/2013/11/foreman-freeipa-integration-guide/ > > But I have an issue, I have a user that has limited roles for Host Enrollment, including > "Add Host" and "Remove Host" permissions. Remove Host doesn't work like I expect: > > $ ipa host-del testbuild.bitbin.de > ipa: ERROR: Insufficient access: not allowed to perform this command > Failed while deleting host from IPA. > > Logs: > > [Mon Nov 11 23:03:35 2013] [error] ipa: INFO: registration at BITBIN.DE: host_del((u'testbuild.bitbin.de',), updatedns=False): ACIError > > Is there an additional permission I need? I tried a bunch of different permissions > but I couldn't figure out the right one to give. There should not be any additional permission required. I tested the procedure according to your log and deleting hosts as "foreman" user worked for me. Can you please send the role and privilege entry so that I can check for correctness? # ipa role-show "Host Enrollment" # ipa privilege-show "Host Enrollment" Thanks. Martin From stbenjam at redhat.com Tue Nov 12 13:14:37 2013 From: stbenjam at redhat.com (Stephen Benjamin) Date: Tue, 12 Nov 2013 08:14:37 -0500 (EST) Subject: [Freeipa-users] "Remove Host" Permission Not Working In-Reply-To: <5281ED60.4010206@redhat.com> References: <1974868340.20671799.1384208087542.JavaMail.root@redhat.com> <5281ED60.4010206@redhat.com> Message-ID: <906172477.21011311.1384262077519.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Martin Kosek" > To: "Stephen Benjamin" , freeipa-users at redhat.com > Sent: Tuesday, November 12, 2013 9:57:04 AM > Subject: Re: [Freeipa-users] "Remove Host" Permission Not Working e out the right one to give. > > There should not be any additional permission required. I tested the > procedure > according to your log and deleting hosts as "foreman" user worked for me. Can > you please send the role and privilege entry so that I can check for > correctness? > > # ipa role-show "Host Enrollment" > # ipa privilege-show "Host Enrollment" It works this morning, but I didn't change anything. Maybe some delay in the change taking effect? or user error somewhere. Thanks Stephen From rmeggins at redhat.com Tue Nov 12 14:38:08 2013 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 12 Nov 2013 07:38:08 -0700 Subject: [Freeipa-users] Active Directory Sync user rights? In-Reply-To: References: Message-ID: <52823D50.9080104@redhat.com> On 11/12/2013 01:29 AM, gflwqs gflwqs wrote: > Hi, > I have created the sync user with: > - *Replicating directory changes* rights to the synchronized Active > Directory subtree. > - A member of the *Account Operator* and *Enterprise Read-Only Domain > controller* groups. > > > The user attribute syncronization is working fine, however the passync > from IPA to AD does not work, i get this error message when i change a > password for a user from IPA: > (00000005: SecErr: DSID-031A121F, problem 4003 (INSUFF_ACCESS_RIGHTS), > data 0 ) for modify operation > > If i add the sync user to the Domain Admins group it works, however > according to the docs this should not be necessary? http://port389.org/wiki/Howto:WindowsSync#Creating_AD_User_with_Replication_Rights > > > > > _______________________________________________ > 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 abontempi at dbmsrl.com Tue Nov 12 14:56:58 2013 From: abontempi at dbmsrl.com (Andrea Bontempi) Date: Tue, 12 Nov 2013 15:56:58 +0100 (CET) Subject: [Freeipa-users] Installation issues with sub-ca. In-Reply-To: <527BA94A.9010400@redhat.com> References: <1008786015.35062.1383756329711.JavaMail.root@dbmsrl.com> <527A74FC.5050501@redhat.com> <1138098293.38547.1383827961817.JavaMail.root@dbmsrl.com> <527BA94A.9010400@redhat.com> Message-ID: <1824702199.51976.1384268218544.JavaMail.root@dbmsrl.com> I found the reason for the failure of the installation. The script uses a NSS db locate under /tmp: ------------------------------------------------------------------------------- Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI ipa-ca-agent u,u,u Certificate Authority - dbmsrl.com ,,c D.B.M. CA - dbmsrl.com c,c, testnick P,, ------------------------------------------------------------------------------- The trust attributes are strange (not trusted) and the chain is broken: ------------------------------------------------------------------------------- [root at dbm13 cert]# certutil -d [temp db] -O -n "Certificate Authority - dbmsrl.com" "D.B.M. CA - dbmsrl.com" [O=dbmsrl.com,OU=office,OU=services,CN=D.B.M. CA] "Certificate Authority - dbmsrl.com" [CN=Certificate Authority,O=DBMSRL.COM] [root at dbm13 cert]# certutil -d [temp db] -O -n "ipa-ca-agent" "ipa-ca-agent" [CN=ipa-ca-agent,O=DBMSRL.COM] ------------------------------------------------------------------------------- I try to export all the certificates in PEM format, if i check the signature with openssl all work perfectly... The chain is valid, but NSS don't see it for "ipa-ca-agent" certificate. (sslget return "SSL_ERROR_UNKNOWN_CA_ALERT" when the script try to use this certificate.) Now i know what is the problem, but i don't know how fix it XD Can anyone help me? Thank you From mkosek at redhat.com Tue Nov 12 15:53:14 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 12 Nov 2013 16:53:14 +0100 Subject: [Freeipa-users] "Remove Host" Permission Not Working - SOLVED In-Reply-To: <906172477.21011311.1384262077519.JavaMail.root@redhat.com> References: <1974868340.20671799.1384208087542.JavaMail.root@redhat.com> <5281ED60.4010206@redhat.com> <906172477.21011311.1384262077519.JavaMail.root@redhat.com> Message-ID: <52824EEA.9000508@redhat.com> On 11/12/2013 02:14 PM, Stephen Benjamin wrote: > ----- Original Message ----- >> From: "Martin Kosek" >> To: "Stephen Benjamin" , freeipa-users at redhat.com >> Sent: Tuesday, November 12, 2013 9:57:04 AM >> Subject: Re: [Freeipa-users] "Remove Host" Permission Not Working > e out the right one to give. >> >> There should not be any additional permission required. I tested the >> procedure >> according to your log and deleting hosts as "foreman" user worked for me. Can >> you please send the role and privilege entry so that I can check for >> correctness? >> >> # ipa role-show "Host Enrollment" >> # ipa privilege-show "Host Enrollment" > > It works this morning, but I didn't change anything. Maybe some > delay in the change taking effect? or user error somewhere. > > > Thanks > > > Stephen > Not sure, maybe you tested it before memberOf plugin added memberOf link and the new permissions/privileges were not applied yet. Anyway, I am glad you have it working now. Martin From rcritten at redhat.com Tue Nov 12 16:36:26 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 12 Nov 2013 11:36:26 -0500 Subject: [Freeipa-users] Installation issues with sub-ca. In-Reply-To: <1824702199.51976.1384268218544.JavaMail.root@dbmsrl.com> References: <1008786015.35062.1383756329711.JavaMail.root@dbmsrl.com> <527A74FC.5050501@redhat.com> <1138098293.38547.1383827961817.JavaMail.root@dbmsrl.com> <527BA94A.9010400@redhat.com> <1824702199.51976.1384268218544.JavaMail.root@dbmsrl.com> Message-ID: <5282590A.2030500@redhat.com> Andrea Bontempi wrote: > I found the reason for the failure of the installation. > > The script uses a NSS db locate under /tmp: > > ------------------------------------------------------------------------------- > Certificate Nickname Trust Attributes > SSL,S/MIME,JAR/XPI > > ipa-ca-agent u,u,u > Certificate Authority - dbmsrl.com ,,c > D.B.M. CA - dbmsrl.com c,c, > testnick P,, > ------------------------------------------------------------------------------- > > The trust attributes are strange (not trusted) and the chain is broken: > > ------------------------------------------------------------------------------- > [root at dbm13 cert]# certutil -d [temp db] -O -n "Certificate Authority - dbmsrl.com" > "D.B.M. CA - dbmsrl.com" [O=dbmsrl.com,OU=office,OU=services,CN=D.B.M. CA] > > "Certificate Authority - dbmsrl.com" [CN=Certificate Authority,O=DBMSRL.COM] > > [root at dbm13 cert]# certutil -d [temp db] -O -n "ipa-ca-agent" > "ipa-ca-agent" [CN=ipa-ca-agent,O=DBMSRL.COM] > ------------------------------------------------------------------------------- > > I try to export all the certificates in PEM format, if i check the signature with openssl all work perfectly... > > The chain is valid, but NSS don't see it for "ipa-ca-agent" certificate. > > (sslget return "SSL_ERROR_UNKNOWN_CA_ALERT" when the script try to use this certificate.) > > Now i know what is the problem, but i don't know how fix it XD > > Can anyone help me? This is basically what I saw too. I'm waiting on someone from the NSS team to get back to me. This must have something to do with the way that OpenSSL validates certs vs NSS. Apparently NSS is being more picky but I don't know why yet. rob From jdennis at redhat.com Tue Nov 12 17:36:49 2013 From: jdennis at redhat.com (John Dennis) Date: Tue, 12 Nov 2013 12:36:49 -0500 Subject: [Freeipa-users] Installation issues with sub-ca. In-Reply-To: <5282590A.2030500@redhat.com> References: <1008786015.35062.1383756329711.JavaMail.root@dbmsrl.com> <527A74FC.5050501@redhat.com> <1138098293.38547.1383827961817.JavaMail.root@dbmsrl.com> <527BA94A.9010400@redhat.com> <1824702199.51976.1384268218544.JavaMail.root@dbmsrl.com> <5282590A.2030500@redhat.com> Message-ID: <52826731.7020502@redhat.com> On 11/12/2013 11:36 AM, Rob Crittenden wrote: > This is basically what I saw too. I'm waiting on someone from the NSS > team to get back to me. This must have something to do with the way that > OpenSSL validates certs vs NSS. Apparently NSS is being more picky but I > don't know why yet. FWIW the current version of python-nss allows you to run NSS cert validation in logging mode, you'll get back a list of errors detailing everything NSS found at fault. Now having said that I'll also note the validation information NSS generates can sometimes be less than wonderful, but at least you'll be getting an insight into where NSS is finding fault. There is an example Python script doc/examples/verify_cert.py which you can run to validate a cert, you can turn on the validation logging with the --log command line arg. The example script also illustrates how to do cert validation logging. The script is contained in the python-nss-doc subpackage. You'll need to running python-nss >= 0.14. -- John From nicklas.bjork at skalarit.se Tue Nov 12 20:11:20 2013 From: nicklas.bjork at skalarit.se (=?ISO-8859-1?Q?Nicklas_Bj=F6rk?=) Date: Tue, 12 Nov 2013 21:11:20 +0100 Subject: [Freeipa-users] Pure Kerberos login on Windows stopped working Message-ID: <52828B68.3060108@skalarit.se> In our evironment we have very limited amount of shared virtual Windows 7 machines. We haven't really seen any value in setting up an AD domain for them, but have been relying on pure Kerberos authentication using the ksetup procedure (http://www.freeipa.org/page/Windows_authentication_against_FreeIPA). Recently the LDAP in our FreeIPA 3.0 was updated with the task to add SIDs to all old user accounts (the newer ones would already have a SID), but that made the Kerberos logon stop working for remote desktop connections. Logging on to the console using the same Kerberos credentials would still work... This seems to be directly related to the addition of SIDs in LDAP, as removing the object class ipantuserattrs and the SID would get it back in order again. Are there any known tricks that could be applied to the Windows machines (or to FreeIPA for that matter) that would make this work again? Best regards Nicklas Bj?rk From simo at redhat.com Tue Nov 12 20:39:41 2013 From: simo at redhat.com (Simo Sorce) Date: Tue, 12 Nov 2013 15:39:41 -0500 Subject: [Freeipa-users] Pure Kerberos login on Windows stopped working In-Reply-To: <52828B68.3060108@skalarit.se> References: <52828B68.3060108@skalarit.se> Message-ID: <1384288781.9191.140.camel@willson.li.ssimo.org> On Tue, 2013-11-12 at 21:11 +0100, Nicklas Bj?rk wrote: > In our evironment we have very limited amount of shared virtual Windows > 7 machines. We haven't really seen any value in setting up an AD domain > for them, but have been relying on pure Kerberos authentication using > the ksetup procedure > (http://www.freeipa.org/page/Windows_authentication_against_FreeIPA). > > Recently the LDAP in our FreeIPA 3.0 was updated with the task to add > SIDs to all old user accounts (the newer ones would already have a SID), > but that made the Kerberos logon stop working for remote desktop > connections. Logging on to the console using the same Kerberos > credentials would still work... This seems to be directly related to the > addition of SIDs in LDAP, as removing the object class ipantuserattrs > and the SID would get it back in order again. > > Are there any known tricks that could be applied to the Windows machines > (or to FreeIPA for that matter) that would make this work again? It's odd that adding the SIDs make it not work, I remember reports of people being happy to see it work better. We do have a way to disable setting the MS-PAC on tickets, but I fear it is only for TGS requests and not for the TGT. Have you added SIDs because you are using a trust relationship with an AD domain, and you just wish not to use them for these few Windows machines ? Simo. -- Simo Sorce * Red Hat, Inc * New York From Steven.Jones at vuw.ac.nz Tue Nov 12 20:47:06 2013 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Tue, 12 Nov 2013 20:47:06 +0000 Subject: [Freeipa-users] 2 question on passsync Message-ID: <833D8E48405E064EBC54C84EC6B36E407FB3EDAC@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, Not sure on the details here so please bear with me When passsync is setup some users can be exempted from the sync. So I have 2 questions or requests for features maybe. This feature is good, however there is nothing within the IPA system that I can see that prevents a user manually setting the same password in IPA as they have in AD. So even if we have a written policy that says you cannot do this it looks like we cannot check or enforce it. Hence I see this as an audit failure. So what Im asking is I guess is there any way that when a password sync occurs the "hash" of the IPA password and the "hash" the AD password would be converted to, gets compared and a security violation is raised if they match? If not would this be a useful feature? to me I think it would be something we'd like for audit purposes. Secondly, at the moment it looks like I have to add each user via a command line function. Can we get this setup via a user group? That way its a point and click and its easily visually auditable. regards Steven Jones Technical Specialist - Linux RHCE Victoria University ITS, Level 8 Rankin Brown Building, Wellington, NZ 6012 0064 4 463 6272 From nicklas.bjork at skalarit.se Tue Nov 12 20:50:47 2013 From: nicklas.bjork at skalarit.se (=?UTF-8?B?Tmlja2xhcyBCasO2cms=?=) Date: Tue, 12 Nov 2013 21:50:47 +0100 Subject: [Freeipa-users] Pure Kerberos login on Windows stopped working In-Reply-To: <1384288781.9191.140.camel@willson.li.ssimo.org> References: <52828B68.3060108@skalarit.se> <1384288781.9191.140.camel@willson.li.ssimo.org> Message-ID: <528294A7.30601@skalarit.se> On 2013-11-12 21:39, Simo Sorce wrote: > On Tue, 2013-11-12 at 21:11 +0100, Nicklas Bj?rk wrote: >> In our evironment we have very limited amount of shared virtual Windows >> 7 machines. We haven't really seen any value in setting up an AD domain >> for them, but have been relying on pure Kerberos authentication using >> the ksetup procedure >> (http://www.freeipa.org/page/Windows_authentication_against_FreeIPA). >> >> Recently the LDAP in our FreeIPA 3.0 was updated with the task to add >> SIDs to all old user accounts (the newer ones would already have a SID), >> but that made the Kerberos logon stop working for remote desktop >> connections. Logging on to the console using the same Kerberos >> credentials would still work... This seems to be directly related to the >> addition of SIDs in LDAP, as removing the object class ipantuserattrs >> and the SID would get it back in order again. >> >> Are there any known tricks that could be applied to the Windows machines >> (or to FreeIPA for that matter) that would make this work again? > > It's odd that adding the SIDs make it not work, I remember reports of > people being happy to see it work better. > > We do have a way to disable setting the MS-PAC on tickets, but I fear it > is only for TGS requests and not for the TGT. > > Have you added SIDs because you are using a trust relationship with an > AD domain, and you just wish not to use them for these few Windows > machines ? > > Simo. > Rather than the SIDs, it was the NT-hash I was looking for, to be used in a Radius implementation. The task in LDAP to make the update also added SIDs to all user accounts. The mentioned few Windows machines are the only ones here and there is also no AD available. At an earlier stage I may have tried making a trust using the ipa-adtrust-install against a test-AD that was available for some time, but it's long gone and there are currently no configured trusts. /Nicklas From dpal at redhat.com Tue Nov 12 21:29:39 2013 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 12 Nov 2013 16:29:39 -0500 Subject: [Freeipa-users] 2 question on passsync In-Reply-To: <833D8E48405E064EBC54C84EC6B36E407FB3EDAC@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E407FB3EDAC@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <52829DC3.3090806@redhat.com> On 11/12/2013 03:47 PM, Steven Jones wrote: > Hi, > > Not sure on the details here so please bear with me When passsync is setup some users can be exempted from the sync. > > So I have 2 questions or requests for features maybe. > > This feature is good, however there is nothing within the IPA system that I can see that prevents a user manually setting the same password in IPA as they have in AD. So even if we have a written policy that says you cannot do this it looks like we cannot check or enforce it. Hence I see this as an audit failure. With Winsync/Passsync this is actually a default behavior. The passwords are the same because most of people to the best of our knowledge want it this way. If I get you right you proposal is actually to force a reverse which seems to be a very corner use case based on the information we have. > > So what Im asking is I guess is there any way that when a password sync occurs the "hash" of the IPA password and the "hash" the AD password would be converted to, gets compared and a security violation is raised if they match? Winsync does not sync password hashes. Passsync syncs passwords and then causes the creation of the hashes. Password hashes are attributes that are really not that easily readable to conduct the comparison you suggest. IMO you can make sure that passwords different (if you do not want to have same passwords on both sides) by setting mutually exclusive password policies. For example force all IPA passwords be 12 characters and AD passwords 11 characters or vice verse. This is just an example. > > If not would this be a useful feature? to me I think it would be something we'd like for audit purposes. > > Secondly, at the moment it looks like I have to add each user via a command line function. Can we get this setup via a user group? That way its a point and click and its easily visually auditable. Can you please explain what do you mean by setting it up via user group? It is unclear what you have in mind. Thanks Dmitri > > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University ITS, > > Level 8 Rankin Brown Building, > > Wellington, NZ > > 6012 > > 0064 4 463 6272 > > _______________________________________________ > 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 Steven.Jones at vuw.ac.nz Tue Nov 12 22:44:33 2013 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Tue, 12 Nov 2013 22:44:33 +0000 Subject: [Freeipa-users] 2 question on passsync In-Reply-To: <52829DC3.3090806@redhat.com> References: <833D8E48405E064EBC54C84EC6B36E407FB3EDAC@STAWINCOX10MBX1.staff.vuw.ac.nz>, <52829DC3.3090806@redhat.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E407FB40156@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, "Winsync does not sync password hashes. Passsync syncs passwords and then causes the creation of the hashes." yep, thats whatt I expected, I just didnt word it well. I just wondered if we could receive the plain text password then hash it, then for an excluded user compare hashes and if they match raise an audit alert. What we have is a concern is that if AD gets hacked that certain users such as myself who have more privileges in Linux land could get their Linux side accounts also hacked simply via a malicious password change in AD. This would mean that we might lose all of our linux side as well as the windows side. A way to prevent this is to exclude those certian users from passsync. The issues then is there is nothing stopping an excluded user manually making the passwords the same, despite a written policy. The problem with having different AD and IPA policies while acceptable to me probably is is'nt acceptable for the organisation. To exclude a user from passync the identity guide says run, "ldapmodify -x -D "cn=Directory Manager" -w secret -h ldap.example.com -p 389 dn: cn=ipa_pwd_extop,cn=plugins,cn=config changetype: modify add: passSyncManagersDNs passSyncManagersDNs: uid=user,cn=users,cn=accounts,dc=example,dc=com" Which means every time I want to exclude a user I have to do this via the command line and also I dont see how its easily and quickly auditable either. eg how do I check who is and isnt excluded? Now if its a IPA user group called say "excluded passsync users" and I just drop the user(s) in, its very easy to do and look at to audit. regards Steven Jones Technical Specialist - Linux RHCE Victoria University ITS, Level 8 Rankin Brown Building, Wellington, NZ 6012 0064 4 463 6272 ________________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Dmitri Pal [dpal at redhat.com] Sent: Wednesday, 13 November 2013 10:29 a.m. To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] 2 question on passsync On 11/12/2013 03:47 PM, Steven Jones wrote: > Hi, > > Not sure on the details here so please bear with me When passsync is setup some users can be exempted from the sync. > > So I have 2 questions or requests for features maybe. > > This feature is good, however there is nothing within the IPA system that I can see that prevents a user manually setting the same password in IPA as they have in AD. So even if we have a written policy that says you cannot do this it looks like we cannot check or enforce it. Hence I see this as an audit failure. With Winsync/Passsync this is actually a default behavior. The passwords are the same because most of people to the best of our knowledge want it this way. If I get you right you proposal is actually to force a reverse which seems to be a very corner use case based on the information we have. > > So what Im asking is I guess is there any way that when a password sync occurs the "hash" of the IPA password and the "hash" the AD password would be converted to, gets compared and a security violation is raised if they match? Winsync does not sync password hashes. Passsync syncs passwords and then causes the creation of the hashes. Password hashes are attributes that are really not that easily readable to conduct the comparison you suggest. IMO you can make sure that passwords different (if you do not want to have same passwords on both sides) by setting mutually exclusive password policies. For example force all IPA passwords be 12 characters and AD passwords 11 characters or vice verse. This is just an example. > > If not would this be a useful feature? to me I think it would be something we'd like for audit purposes. > > Secondly, at the moment it looks like I have to add each user via a command line function. Can we get this setup via a user group? That way its a point and click and its easily visually auditable. Can you please explain what do you mean by setting it up via user group? It is unclear what you have in mind. Thanks Dmitri > > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University ITS, > > Level 8 Rankin Brown Building, > > Wellington, NZ > > 6012 > > 0064 4 463 6272 > > _______________________________________________ > 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 dpal at redhat.com Tue Nov 12 22:56:33 2013 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 12 Nov 2013 17:56:33 -0500 Subject: [Freeipa-users] 2 question on passsync In-Reply-To: <833D8E48405E064EBC54C84EC6B36E407FB40156@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E407FB3EDAC@STAWINCOX10MBX1.staff.vuw.ac.nz>, <52829DC3.3090806@redhat.com> <833D8E48405E064EBC54C84EC6B36E407FB40156@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <5282B221.8040401@redhat.com> On 11/12/2013 05:44 PM, Steven Jones wrote: > Hi, > > "Winsync does not sync password hashes. Passsync syncs passwords and then > causes the creation of the hashes." > > yep, thats whatt I expected, I just didnt word it well. > > I just wondered if we could receive the plain text password then hash it, then for an excluded user compare hashes and if they match raise an audit alert. > > What we have is a concern is that if AD gets hacked that certain users such as myself who have more privileges in Linux land could get their Linux side accounts also hacked simply via a malicious password change in AD. This would mean that we might lose all of our linux side as well as the windows side. > > A way to prevent this is to exclude those certian users from passsync. The issues then is there is nothing stopping an excluded user manually making the passwords the same, despite a written policy. > > The problem with having different AD and IPA policies while acceptable to me probably is is'nt acceptable for the organisation. > > To exclude a user from passync the identity guide says run, > > "ldapmodify -x -D "cn=Directory Manager" -w secret -h ldap.example.com -p 389 > dn: cn=ipa_pwd_extop,cn=plugins,cn=config > changetype: modify > add: passSyncManagersDNs > passSyncManagersDNs: uid=user,cn=users,cn=accounts,dc=example,dc=com" > > Which means every time I want to exclude a user I have to do this via the command line and also I dont see how its easily and quickly auditable either. > > eg how do I check who is and isnt excluded? > > Now if its a IPA user group called say "excluded passsync users" and I just drop the user(s) in, its very easy to do and look at to audit. OK that makes sense. This is a reasonable RFE to file. > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University ITS, > > Level 8 Rankin Brown Building, > > Wellington, NZ > > 6012 > > 0064 4 463 6272 > > ________________________________________ > From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Dmitri Pal [dpal at redhat.com] > Sent: Wednesday, 13 November 2013 10:29 a.m. > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] 2 question on passsync > > On 11/12/2013 03:47 PM, Steven Jones wrote: >> Hi, >> >> Not sure on the details here so please bear with me When passsync is setup some users can be exempted from the sync. >> >> So I have 2 questions or requests for features maybe. >> >> This feature is good, however there is nothing within the IPA system that I can see that prevents a user manually setting the same password in IPA as they have in AD. So even if we have a written policy that says you cannot do this it looks like we cannot check or enforce it. Hence I see this as an audit failure. > With Winsync/Passsync this is actually a default behavior. The passwords > are the same because most of people to the best of our knowledge want it > this way. If I get you right you proposal is actually to force a reverse > which seems to be a very corner use case based on the information we have. > > >> So what Im asking is I guess is there any way that when a password sync occurs the "hash" of the IPA password and the "hash" the AD password would be converted to, gets compared and a security violation is raised if they match? > > Winsync does not sync password hashes. Passsync syncs passwords and then > causes the creation of the hashes. Password hashes are attributes that > are really not that easily readable to conduct the comparison you suggest. > > IMO you can make sure that passwords different (if you do not want to > have same passwords on both sides) by setting mutually exclusive > password policies. > For example force all IPA passwords be 12 characters and AD passwords 11 > characters or vice verse. This is just an example. > > >> If not would this be a useful feature? to me I think it would be something we'd like for audit purposes. >> >> Secondly, at the moment it looks like I have to add each user via a command line function. Can we get this setup via a user group? That way its a point and click and its easily visually auditable. > Can you please explain what do you mean by setting it up via user group? > It is unclear what you have in mind. > > > > Thanks > Dmitri > >> >> regards >> >> Steven Jones >> >> Technical Specialist - Linux RHCE >> >> Victoria University ITS, >> >> Level 8 Rankin Brown Building, >> >> Wellington, NZ >> >> 6012 >> >> 0064 4 463 6272 >> >> _______________________________________________ >> 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 -- 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 Tue Nov 12 23:20:46 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 12 Nov 2013 18:20:46 -0500 Subject: [Freeipa-users] 2 question on passsync In-Reply-To: <833D8E48405E064EBC54C84EC6B36E407FB40156@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E407FB3EDAC@STAWINCOX10MBX1.staff.vuw.ac.nz>, <52829DC3.3090806@redhat.com> <833D8E48405E064EBC54C84EC6B36E407FB40156@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <5282B7CE.9090703@redhat.com> Steven Jones wrote: > Hi, > > "Winsync does not sync password hashes. Passsync syncs passwords and then > causes the creation of the hashes." > > yep, thats whatt I expected, I just didnt word it well. > > I just wondered if we could receive the plain text password then hash it, then for an excluded user compare hashes and if they match raise an audit alert. > > What we have is a concern is that if AD gets hacked that certain users such as myself who have more privileges in Linux land could get their Linux side accounts also hacked simply via a malicious password change in AD. This would mean that we might lose all of our linux side as well as the windows side. > > A way to prevent this is to exclude those certian users from passsync. The issues then is there is nothing stopping an excluded user manually making the passwords the same, despite a written policy. > > The problem with having different AD and IPA policies while acceptable to me probably is is'nt acceptable for the organisation. > > To exclude a user from passync the identity guide says run, > > "ldapmodify -x -D "cn=Directory Manager" -w secret -h ldap.example.com -p 389 > dn: cn=ipa_pwd_extop,cn=plugins,cn=config > changetype: modify > add: passSyncManagersDNs > passSyncManagersDNs: uid=user,cn=users,cn=accounts,dc=example,dc=com" > > Which means every time I want to exclude a user I have to do this via the command line and also I dont see how its easily and quickly auditable either. > > eg how do I check who is and isnt excluded? > > Now if its a IPA user group called say "excluded passsync users" and I just drop the user(s) in, its very easy to do and look at to audit. This isn't what passSyncManagersDNs does. What this value does is list the users who can change a password without requiring a reset of that password. Without this then when a new password is synced from AD it would require a reset, which sort of defeats the point of syncing passwords. I like your idea of a group, can you file an RFE on this? rob From Steven.Jones at vuw.ac.nz Tue Nov 12 23:59:17 2013 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Tue, 12 Nov 2013 23:59:17 +0000 Subject: [Freeipa-users] 2 question on passsync In-Reply-To: <5282B7CE.9090703@redhat.com> References: <833D8E48405E064EBC54C84EC6B36E407FB3EDAC@STAWINCOX10MBX1.staff.vuw.ac.nz>, <52829DC3.3090806@redhat.com> <833D8E48405E064EBC54C84EC6B36E407FB40156@STAWINCOX10MBX1.staff.vuw.ac.nz>, <5282B7CE.9090703@redhat.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E407FB406B3@STAWINCOX10MBX1.staff.vuw.ac.nz> Yes will do. regards Steven Jones Technical Specialist - Linux RHCE Victoria University ITS, Level 8 Rankin Brown Building, Wellington, NZ 6012 0064 4 463 6272 ________________________________________ From: Rob Crittenden [rcritten at redhat.com] Sent: Wednesday, 13 November 2013 12:20 p.m. To: Steven Jones; freeipa-users at redhat.com Subject: Re: [Freeipa-users] 2 question on passsync Steven Jones wrote: > Hi, > > "Winsync does not sync password hashes. Passsync syncs passwords and then > causes the creation of the hashes." > > yep, thats whatt I expected, I just didnt word it well. > > I just wondered if we could receive the plain text password then hash it, then for an excluded user compare hashes and if they match raise an audit alert. > > What we have is a concern is that if AD gets hacked that certain users such as myself who have more privileges in Linux land could get their Linux side accounts also hacked simply via a malicious password change in AD. This would mean that we might lose all of our linux side as well as the windows side. > > A way to prevent this is to exclude those certian users from passsync. The issues then is there is nothing stopping an excluded user manually making the passwords the same, despite a written policy. > > The problem with having different AD and IPA policies while acceptable to me probably is is'nt acceptable for the organisation. > > To exclude a user from passync the identity guide says run, > > "ldapmodify -x -D "cn=Directory Manager" -w secret -h ldap.example.com -p 389 > dn: cn=ipa_pwd_extop,cn=plugins,cn=config > changetype: modify > add: passSyncManagersDNs > passSyncManagersDNs: uid=user,cn=users,cn=accounts,dc=example,dc=com" > > Which means every time I want to exclude a user I have to do this via the command line and also I dont see how its easily and quickly auditable either. > > eg how do I check who is and isnt excluded? > > Now if its a IPA user group called say "excluded passsync users" and I just drop the user(s) in, its very easy to do and look at to audit. This isn't what passSyncManagersDNs does. What this value does is list the users who can change a password without requiring a reset of that password. Without this then when a new password is synced from AD it would require a reset, which sort of defeats the point of syncing passwords. I like your idea of a group, can you file an RFE on this? rob From Steven.Jones at vuw.ac.nz Wed Nov 13 00:14:08 2013 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Wed, 13 Nov 2013 00:14:08 +0000 Subject: [Freeipa-users] 2 question on passsync In-Reply-To: <5282B7CE.9090703@redhat.com> References: <833D8E48405E064EBC54C84EC6B36E407FB3EDAC@STAWINCOX10MBX1.staff.vuw.ac.nz>, <52829DC3.3090806@redhat.com> <833D8E48405E064EBC54C84EC6B36E407FB40156@STAWINCOX10MBX1.staff.vuw.ac.nz>, <5282B7CE.9090703@redhat.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E407FB40758@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi >From the RH manual, "15.6.3. Exempting Active Directory Users from Password Synchronization" So the heading says I can? or I cannot? by running, "ldapmodify -x -D "cn=Directory Manager" -w secret -h ldap.example.com -p 389 dn: cn=ipa_pwd_extop,cn=plugins,cn=config changetype: modify add: passSyncManagersDNs passSyncManagersDNs: uid=user,cn=users,cn=accounts,dc=example,dc=com" Where the user would say be me, so I have to have a different password in IPA to AD. If I cannot then the manual heading above is very confusing... In terms of "Without this then when a new password is synced from AD it would require a reset, which sort of defeats the point of syncing passwords." I did wonder but when I tested a normal user, there was no password reset required, the AD password just worked with teh rhle6 client login, no issues, no reset. So I am confused. regards Steven Jones Technical Specialist - Linux RHCE Victoria University ITS, Level 8 Rankin Brown Building, Wellington, NZ 6012 0064 4 463 6272 clude a user from passync the identity guide says run, > > "ldapmodify -x -D "cn=Directory Manager" -w secret -h ldap.example.com -p 389 > dn: cn=ipa_pwd_extop,cn=plugins,cn=config > changetype: modify > add: passSyncManagersDNs > passSyncManagersDNs: uid=user,cn=users,cn=accounts,dc=example,dc=com" > > Which means every time I want to exclude a user I have to do this via the command line and also I dont see how its easily and quickly auditable either. > > eg how do I check who is and isnt excluded? > > Now if its a IPA user group called say "excluded passsync users" and I just drop the user(s) in, its very easy to do and look at to audit. This isn't what passSyncManagersDNs does. What this value does is list the users who can change a password without requiring a reset of that password. Without this then when a new password is synced from AD it would require a reset, which sort of defeats the point of syncing passwords. I like your idea of a group, can you file an RFE on this? rob From simo at redhat.com Wed Nov 13 01:03:09 2013 From: simo at redhat.com (Simo Sorce) Date: Tue, 12 Nov 2013 20:03:09 -0500 Subject: [Freeipa-users] 2 question on passsync In-Reply-To: <833D8E48405E064EBC54C84EC6B36E407FB40758@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E407FB3EDAC@STAWINCOX10MBX1.staff.vuw.ac.nz> , <52829DC3.3090806@redhat.com> <833D8E48405E064EBC54C84EC6B36E407FB40156@STAWINCOX10MBX1.staff.vuw.ac.nz> , <5282B7CE.9090703@redhat.com> <833D8E48405E064EBC54C84EC6B36E407FB40758@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <1384304589.9191.168.camel@willson.li.ssimo.org> On Wed, 2013-11-13 at 00:14 +0000, Steven Jones wrote: > Hi > > >From the RH manual, > > "15.6.3. Exempting Active Directory Users from Password Synchronization" This paragraph is completely misguiding, sorry, we'll open a doc bug to correct the explanation. The list of uses set in passSyncManagersDNs is allowed to set passwords for any user without triggering password policy requirements. In the synchronization case it means that although an 'administrative' account is resetting another user passwrod, that password is not marked for immediate reset like it normally happens, it is indeed considered valid and proper. It has nothing to do with expempting users from password synchronization. Please DO NOT list regular, non administrative users in that attribute. Simo. > So the heading says I can? > > or I cannot? > > by running, > > "ldapmodify -x -D "cn=Directory Manager" -w secret -h ldap.example.com -p 389 > dn: cn=ipa_pwd_extop,cn=plugins,cn=config > changetype: modify > add: passSyncManagersDNs passSyncManagersDNs: uid=user,cn=users,cn=accounts,dc=example,dc=com" > > Where the user would say be me, so I have to have a different password in IPA to AD. > > If I cannot then the manual heading above is very confusing... > > In terms of > > "Without this then when a new password is synced from AD it would require > a reset, which sort of defeats the point of syncing passwords." > > I did wonder but when I tested a normal user, there was no password reset required, the AD password just worked with teh rhle6 client login, no issues, no reset. > > So I am confused. > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University ITS, > > Level 8 Rankin Brown Building, > > Wellington, NZ > > 6012 > > 0064 4 463 6272 > > clude a user from passync the identity guide says run, > > > > "ldapmodify -x -D "cn=Directory Manager" -w secret -h ldap.example.com -p 389 > > dn: cn=ipa_pwd_extop,cn=plugins,cn=config > > changetype: modify > > add: passSyncManagersDNs > > passSyncManagersDNs: uid=user,cn=users,cn=accounts,dc=example,dc=com" > > > > Which means every time I want to exclude a user I have to do this via the command line and also I dont see how its easily and quickly auditable either. > > > > eg how do I check who is and isnt excluded? > > > > Now if its a IPA user group called say "excluded passsync users" and I just drop the user(s) in, its very easy to do and look at to audit. > > This isn't what passSyncManagersDNs does. What this value does is list > the users who can change a password without requiring a reset of that > password. > > Without this then when a new password is synced from AD it would require > a reset, which sort of defeats the point of syncing passwords. > > I like your idea of a group, can you file an RFE on this? > > rob > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Simo Sorce * Red Hat, Inc * New York From abontempi at dbmsrl.com Wed Nov 13 10:54:43 2013 From: abontempi at dbmsrl.com (Andrea Bontempi) Date: Wed, 13 Nov 2013 11:54:43 +0100 (CET) Subject: [Freeipa-users] Installation issues with sub-ca. In-Reply-To: <52826731.7020502@redhat.com> References: <1008786015.35062.1383756329711.JavaMail.root@dbmsrl.com> <527A74FC.5050501@redhat.com> <1138098293.38547.1383827961817.JavaMail.root@dbmsrl.com> <527BA94A.9010400@redhat.com> <1824702199.51976.1384268218544.JavaMail.root@dbmsrl.com> <5282590A.2030500@redhat.com> <52826731.7020502@redhat.com> Message-ID: <638724550.54180.1384340083404.JavaMail.root@dbmsrl.com> Ok, this is funny: ----------------------------------------------------------------------------------------------------- [root at dbm13 ca_rotta]# certutil -d sql:[nss db] -K certutil: Checking token "NSS Certificate DB" in slot "NSS User Private Key and Certificate Services" Enter Password or Pin for "NSS Certificate DB": < 0> rsa [hidden] ipa-ca-agent ----------------------------------------------------------------------------------------------------- The sub-ca doesn't have the private key. This is ridiculous... FreeIPA gave me the CSR... When i try to validate "ipa-ca-agent" with certutil i get this error: "Peer's certificate issuer is not recognized" (obvious if the certificate issuer does not have the private key) Andrea Bontempi From david.kreuter at bytesource.net Wed Nov 13 16:26:32 2013 From: david.kreuter at bytesource.net (David Kreuter) Date: Wed, 13 Nov 2013 17:26:32 +0100 (CET) Subject: [Freeipa-users] Sudo rule still working after deactivation In-Reply-To: Message-ID: During our evaluation phase we're facing following problem. One particular user were granted sudo permission with the help of a sudo rule. The user can successfully access the host via SSH and switched to user root by using the sudo command, which was enabled for the user with the sudo rule. After that the sudo rule was disabled and the user tried to login again and switching to root was still possible. After deleting the SSSD cache files and restarting the service sudo did not work anymore, as excepted. How long does it take until the sudo rules are refreshed in SSSD cache? I know that there are three different refresh mechanism (full, smart, rule). Full and smart refresh mechanism are performed periodically dependent on the settings in SSSD configuration file and rule method should refresh the users's specific rules after each login, what apparently was not the case for my test scenario. Please correct me if i'm wrong. Of course I can set the interval for smart refresh to a minimum of 10 seconds, but this would cause a lot of traffic. How can I configure SSSD to update the rules during each login of the user? Following components are used: - FreeIPA server freeipa-server.x86_64 3.3.2-1.fc19 - FreeIPA client on CentosOS ipa-client.x86_64 3.0.0-26.el6_4.4 - SSSD sudo integration --- /etc/sssd/sssd.conf --- [domain/example.info] debug_level = 0xFFF0 cache_credentials = True krb5_store_password_if_offline = True ipa_domain = example.info id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = chef01.example.info chpass_provider = ipa ipa_server = _srv_, ipa01.example.info ldap_tls_cacert = /etc/ipa/ca.crt sudo_provider = ldap ldap_uri = ldap://ipa01.example.info ldap_sudo_search_base = ou=sudoers,dc=example,dc=info ldap_schema=IPA ldap_sasl_mech = GSSAPI ldap_sasl_authid = host/chef01.example.info ldap_sasl_realm = EXAMPLE.INFO krb5_server = ipa01.example.info [sssd] debug_level = 0x0400 services = nss, pam, ssh, sudo config_file_version = 2 domains = example.info [nss] [pam] [sudo] debug_level = 0xFFF0 [autofs] [ssh] [pac] --- /etc/sssd/sssd.conf --- I tested the test scenario with very small intervals and the rules were properly updated. ldap_sudo_full_refresh_interval = 30 ldap_sudo_smart_refresh_interval = 15 Is this a proper solution or can configure SSSD in a way that rules were updated during each uses's login? I appreciate any help and thanking you in advance. Cheers, David From jhrozek at redhat.com Wed Nov 13 16:40:10 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 13 Nov 2013 17:40:10 +0100 Subject: [Freeipa-users] Sudo rule still working after deactivation In-Reply-To: References: Message-ID: <20131113164010.GJ9613@hendrix.brq.redhat.com> On Wed, Nov 13, 2013 at 05:26:32PM +0100, David Kreuter wrote: > During our evaluation phase we're facing following problem. One particular user were granted sudo permission with the help of a sudo rule. The user can successfully access the host via SSH and switched to user root by using the sudo command, which was enabled for the user with the sudo rule. After that the sudo rule was disabled and the user tried to login again and switching to root was still possible. > > After deleting the SSSD cache files and restarting the service sudo did not work anymore, as excepted. > > How long does it take until the sudo rules are refreshed in SSSD cache? I know that there are three different refresh mechanism (full, smart, rule). Full and smart refresh mechanism are performed periodically dependent on the settings in SSSD configuration file and rule method should refresh the users's specific rules after each login, what apparently was not the case for my test scenario. Please correct me if i'm wrong. Of course I can set the interval for smart refresh to a minimum of 10 seconds, but this would cause a lot of traffic. > > How can I configure SSSD to update the rules during each login of the user? Hi David, Pavel Brezina (CC-ed) would know for sure as he wrote the sudo integration, but I think the trick could be to force the rules refresh to run more often, as you noted, detecting the removed rules. I'd suggest to lower the entry_cache_sudo_timeout to make the rules expire faster which would trigger the rules refresh which, if it detected rules were removed would trigger the full refresh. Currently there's no config option that would tie login and rules refresh update. From pbrezina at redhat.com Wed Nov 13 17:10:33 2013 From: pbrezina at redhat.com (=?UTF-8?B?UGF2ZWwgQsWZZXppbmE=?=) Date: Wed, 13 Nov 2013 18:10:33 +0100 Subject: [Freeipa-users] Sudo rule still working after deactivation In-Reply-To: <20131113164010.GJ9613@hendrix.brq.redhat.com> References: <20131113164010.GJ9613@hendrix.brq.redhat.com> Message-ID: <5283B289.40205@redhat.com> On 11/13/2013 05:40 PM, Jakub Hrozek wrote: > On Wed, Nov 13, 2013 at 05:26:32PM +0100, David Kreuter wrote: >> During our evaluation phase we're facing following problem. One particular user were granted sudo permission with the help of a sudo rule. The user can successfully access the host via SSH and switched to user root by using the sudo command, which was enabled for the user with the sudo rule. After that the sudo rule was disabled and the user tried to login again and switching to root was still possible. >> >> After deleting the SSSD cache files and restarting the service sudo did not work anymore, as excepted. >> >> How long does it take until the sudo rules are refreshed in SSSD cache? I know that there are three different refresh mechanism (full, smart, rule). Full and smart refresh mechanism are performed periodically dependent on the settings in SSSD configuration file and rule method should refresh the users's specific rules after each login, what apparently was not the case for my test scenario. Please correct me if i'm wrong. Of course I can set the interval for smart refresh to a minimum of 10 seconds, but this would cause a lot of traffic. >> >> How can I configure SSSD to update the rules during each login of the user? > > Hi David, > > Pavel Brezina (CC-ed) would know for sure as he wrote the sudo > integration, but I think the trick could be to force the rules refresh > to run more often, as you noted, detecting the removed rules. > > I'd suggest to lower the entry_cache_sudo_timeout to make the rules expire > faster which would trigger the rules refresh which, if it detected rules > were removed would trigger the full refresh. Hi, this is completely correct answer. > Currently there's no config option that would tie login and rules > refresh update. And this sounds like a nice RFE :-) From rcritten at redhat.com Wed Nov 13 18:09:26 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 13 Nov 2013 13:09:26 -0500 Subject: [Freeipa-users] Installation issues with sub-ca. In-Reply-To: <638724550.54180.1384340083404.JavaMail.root@dbmsrl.com> References: <1008786015.35062.1383756329711.JavaMail.root@dbmsrl.com> <527A74FC.5050501@redhat.com> <1138098293.38547.1383827961817.JavaMail.root@dbmsrl.com> <527BA94A.9010400@redhat.com> <1824702199.51976.1384268218544.JavaMail.root@dbmsrl.com> <5282590A.2030500@redhat.com> <52826731.7020502@redhat.com> <638724550.54180.1384340083404.JavaMail.root@dbmsrl.com> Message-ID: <5283C056.9060006@redhat.com> Andrea Bontempi wrote: > Ok, this is funny: > > ----------------------------------------------------------------------------------------------------- > [root at dbm13 ca_rotta]# certutil -d sql:[nss db] -K > certutil: Checking token "NSS Certificate DB" in slot "NSS User Private Key and Certificate Services" > Enter Password or Pin for "NSS Certificate DB": > < 0> rsa [hidden] ipa-ca-agent > ----------------------------------------------------------------------------------------------------- > > The sub-ca doesn't have the private key. This is ridiculous... FreeIPA gave me the CSR... > > When i try to validate "ipa-ca-agent" with certutil i get this error: > > "Peer's certificate issuer is not recognized" > > (obvious if the certificate issuer does not have the private key) This is incorrect. To validate a certificate you only need the CA public keys, not the private ones. Only having the ipa-ca-agent key is right. This is a temporary database, not the CA database. We are using this cert to request some information about itself from the CA in this case. I think there is an issue with one of the CA certs but I've yet to duplicate it or identify what is wrong. I'm still waiting on word back from one of the NSS devs. rob From simo at redhat.com Wed Nov 13 19:00:52 2013 From: simo at redhat.com (Simo Sorce) Date: Wed, 13 Nov 2013 14:00:52 -0500 Subject: [Freeipa-users] Pure Kerberos login on Windows stopped working In-Reply-To: <528294A7.30601@skalarit.se> References: <52828B68.3060108@skalarit.se> <1384288781.9191.140.camel@willson.li.ssimo.org> <528294A7.30601@skalarit.se> Message-ID: <1384369252.9191.180.camel@willson.li.ssimo.org> On Tue, 2013-11-12 at 21:50 +0100, Nicklas Bj?rk wrote: > On 2013-11-12 21:39, Simo Sorce wrote: > > On Tue, 2013-11-12 at 21:11 +0100, Nicklas Bj?rk wrote: > >> In our evironment we have very limited amount of shared virtual Windows > >> 7 machines. We haven't really seen any value in setting up an AD domain > >> for them, but have been relying on pure Kerberos authentication using > >> the ksetup procedure > >> (http://www.freeipa.org/page/Windows_authentication_against_FreeIPA). > >> > >> Recently the LDAP in our FreeIPA 3.0 was updated with the task to add > >> SIDs to all old user accounts (the newer ones would already have a SID), > >> but that made the Kerberos logon stop working for remote desktop > >> connections. Logging on to the console using the same Kerberos > >> credentials would still work... This seems to be directly related to the > >> addition of SIDs in LDAP, as removing the object class ipantuserattrs > >> and the SID would get it back in order again. > >> > >> Are there any known tricks that could be applied to the Windows machines > >> (or to FreeIPA for that matter) that would make this work again? > > > > It's odd that adding the SIDs make it not work, I remember reports of > > people being happy to see it work better. > > > > We do have a way to disable setting the MS-PAC on tickets, but I fear it > > is only for TGS requests and not for the TGT. > > > > Have you added SIDs because you are using a trust relationship with an > > AD domain, and you just wish not to use them for these few Windows > > machines ? > > > > Simo. > > > > Rather than the SIDs, it was the NT-hash I was looking for, to be used > in a Radius implementation. The task in LDAP to make the update also > added SIDs to all user accounts. > > The mentioned few Windows machines are the only ones here and there is > also no AD available. At an earlier stage I may have tried making a > trust using the ipa-adtrust-install against a test-AD that was available > for some time, but it's long gone and there are currently no configured > trusts. I see, but the SID is required by the objectclass that allows you to set the NThash. One way to resolve that would be to use a different objectclass so you do not have to set the SID, but I ma not sure NThash would be automatically refreshed at password change then. Can you tell me exactly what error do your Win7 machines return ? Simo. -- Simo Sorce * Red Hat, Inc * New York From nicklas.bjork at skalarit.se Wed Nov 13 19:19:18 2013 From: nicklas.bjork at skalarit.se (=?UTF-8?B?Tmlja2xhcyBCasO2cms=?=) Date: Wed, 13 Nov 2013 20:19:18 +0100 Subject: [Freeipa-users] Pure Kerberos login on Windows stopped working In-Reply-To: <1384369252.9191.180.camel@willson.li.ssimo.org> References: <52828B68.3060108@skalarit.se> <1384288781.9191.140.camel@willson.li.ssimo.org> <528294A7.30601@skalarit.se> <1384369252.9191.180.camel@willson.li.ssimo.org> Message-ID: <5283D0B6.3000409@skalarit.se> On 2013-11-13 20:00, Simo Sorce wrote: > On Tue, 2013-11-12 at 21:50 +0100, Nicklas Bj?rk wrote: >> On 2013-11-12 21:39, Simo Sorce wrote: >>> On Tue, 2013-11-12 at 21:11 +0100, Nicklas Bj?rk wrote: >>>> In our evironment we have very limited amount of shared virtual Windows >>>> 7 machines. We haven't really seen any value in setting up an AD domain >>>> for them, but have been relying on pure Kerberos authentication using >>>> the ksetup procedure >>>> (http://www.freeipa.org/page/Windows_authentication_against_FreeIPA). >>>> >>>> Recently the LDAP in our FreeIPA 3.0 was updated with the task to add >>>> SIDs to all old user accounts (the newer ones would already have a SID), >>>> but that made the Kerberos logon stop working for remote desktop >>>> connections. Logging on to the console using the same Kerberos >>>> credentials would still work... This seems to be directly related to the >>>> addition of SIDs in LDAP, as removing the object class ipantuserattrs >>>> and the SID would get it back in order again. >>>> >>>> Are there any known tricks that could be applied to the Windows machines >>>> (or to FreeIPA for that matter) that would make this work again? >>> >>> It's odd that adding the SIDs make it not work, I remember reports of >>> people being happy to see it work better. >>> >>> We do have a way to disable setting the MS-PAC on tickets, but I fear it >>> is only for TGS requests and not for the TGT. >>> >>> Have you added SIDs because you are using a trust relationship with an >>> AD domain, and you just wish not to use them for these few Windows >>> machines ? >>> >>> Simo. >>> >> >> Rather than the SIDs, it was the NT-hash I was looking for, to be used >> in a Radius implementation. The task in LDAP to make the update also >> added SIDs to all user accounts. >> >> The mentioned few Windows machines are the only ones here and there is >> also no AD available. At an earlier stage I may have tried making a >> trust using the ipa-adtrust-install against a test-AD that was available >> for some time, but it's long gone and there are currently no configured >> trusts. > > I see, but the SID is required by the objectclass that allows you to set > the NThash. One way to resolve that would be to use a different > objectclass so you do not have to set the SID, but I ma not sure NThash > would be automatically refreshed at password change then. > > Can you tell me exactly what error do your Win7 machines return ? > > Simo. > I have actually spent a few hours today trying to figure out under what circumstances it stops working. It seems like authentication with Kerberos always works, but for some reason it won't let the user create a session when connecting using RDP, when the SID is available in the directory (thus also in the kerberos ticket, I would assume?). The local user account is in the Administrators as well as the Remote Desktop Users groups, but the error message given at logon is "The requested session access is denied.". There must be some way to get more information on what the system is doing and what it wants. Perhaps it would be possible to increase the amount of debugging information in the event viewer? Maybe it would start working again if I flipped the right 0 to a 1 somewhere in the deep registry forest... Nicklas From erinn.looneytriggs at gmail.com Thu Nov 14 01:14:47 2013 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Wed, 13 Nov 2013 18:14:47 -0700 Subject: [Freeipa-users] CA expiration and renewal Message-ID: <52842407.80504@gmail.com> Folks just wanted to touch base again before the American holiday season starts. My CA, which is subordinate to AD CS will be expiring on December 9th, I submitted a bug, y'all drew up docs etc for a plan (thanks). Now I just wanted to see how it was going and if need be what manual steps I will need to take to renew the certificate. Thanks again for the great work, -Erinn From abontempi at dbmsrl.com Thu Nov 14 08:29:35 2013 From: abontempi at dbmsrl.com (Andrea Bontempi) Date: Thu, 14 Nov 2013 09:29:35 +0100 (CET) Subject: [Freeipa-users] Installation issues with sub-ca. In-Reply-To: <5283C056.9060006@redhat.com> References: <1008786015.35062.1383756329711.JavaMail.root@dbmsrl.com> <1138098293.38547.1383827961817.JavaMail.root@dbmsrl.com> <527BA94A.9010400@redhat.com> <1824702199.51976.1384268218544.JavaMail.root@dbmsrl.com> <5282590A.2030500@redhat.com> <52826731.7020502@redhat.com> <638724550.54180.1384340083404.JavaMail.root@dbmsrl.com> <5283C056.9060006@redhat.com> Message-ID: <1383360113.57557.1384417775122.JavaMail.root@dbmsrl.com> > This is incorrect. To validate a certificate you only need the CA public > keys, not the private ones. Only having the ipa-ca-agent key is right. > This is a temporary database, not the CA database. We are using this > cert to request some information about itself from the CA in this case. You're right, I thought that the script use a temporary db to create the final database, but it's only to connect with sslget. > I think there is an issue with one of the CA certs but I've yet to > duplicate it or identify what is wrong. I'm still waiting on word back > from one of the NSS devs. I did some tests: The error occurs when I use a CA managed by EJBCA, if I use a CA generated by openssl or nss everything works properly. The problem is that i can't reproduce the bug in an external nss db... but maybe I don't follow the same steps that uses the installation script. Andrea Bontempi From sbose at redhat.com Thu Nov 14 09:25:46 2013 From: sbose at redhat.com (Sumit Bose) Date: Thu, 14 Nov 2013 10:25:46 +0100 Subject: [Freeipa-users] Pure Kerberos login on Windows stopped working In-Reply-To: <5283D0B6.3000409@skalarit.se> References: <52828B68.3060108@skalarit.se> <1384288781.9191.140.camel@willson.li.ssimo.org> <528294A7.30601@skalarit.se> <1384369252.9191.180.camel@willson.li.ssimo.org> <5283D0B6.3000409@skalarit.se> Message-ID: <20131114092546.GH2726@localhost.localdomain> On Wed, Nov 13, 2013 at 08:19:18PM +0100, Nicklas Bj?rk wrote: > On 2013-11-13 20:00, Simo Sorce wrote: > > On Tue, 2013-11-12 at 21:50 +0100, Nicklas Bj?rk wrote: > >> On 2013-11-12 21:39, Simo Sorce wrote: > >>> On Tue, 2013-11-12 at 21:11 +0100, Nicklas Bj?rk wrote: > >>>> In our evironment we have very limited amount of shared virtual Windows > >>>> 7 machines. We haven't really seen any value in setting up an AD domain > >>>> for them, but have been relying on pure Kerberos authentication using > >>>> the ksetup procedure > >>>> (http://www.freeipa.org/page/Windows_authentication_against_FreeIPA). > >>>> > >>>> Recently the LDAP in our FreeIPA 3.0 was updated with the task to add > >>>> SIDs to all old user accounts (the newer ones would already have a SID), > >>>> but that made the Kerberos logon stop working for remote desktop > >>>> connections. Logging on to the console using the same Kerberos > >>>> credentials would still work... This seems to be directly related to the > >>>> addition of SIDs in LDAP, as removing the object class ipantuserattrs > >>>> and the SID would get it back in order again. > >>>> > >>>> Are there any known tricks that could be applied to the Windows machines > >>>> (or to FreeIPA for that matter) that would make this work again? > >>> > >>> It's odd that adding the SIDs make it not work, I remember reports of > >>> people being happy to see it work better. > >>> > >>> We do have a way to disable setting the MS-PAC on tickets, but I fear it > >>> is only for TGS requests and not for the TGT. > >>> > >>> Have you added SIDs because you are using a trust relationship with an > >>> AD domain, and you just wish not to use them for these few Windows > >>> machines ? > >>> > >>> Simo. > >>> > >> > >> Rather than the SIDs, it was the NT-hash I was looking for, to be used > >> in a Radius implementation. The task in LDAP to make the update also > >> added SIDs to all user accounts. > >> > >> The mentioned few Windows machines are the only ones here and there is > >> also no AD available. At an earlier stage I may have tried making a > >> trust using the ipa-adtrust-install against a test-AD that was available > >> for some time, but it's long gone and there are currently no configured > >> trusts. > > > > I see, but the SID is required by the objectclass that allows you to set > > the NThash. One way to resolve that would be to use a different > > objectclass so you do not have to set the SID, but I ma not sure NThash > > would be automatically refreshed at password change then. > > > > Can you tell me exactly what error do your Win7 machines return ? > > > > Simo. > > > > I have actually spent a few hours today trying to figure out under what > circumstances it stops working. It seems like authentication with > Kerberos always works, but for some reason it won't let the user create > a session when connecting using RDP, when the SID is available in the > directory (thus also in the kerberos ticket, I would assume?). The local > user account is in the Administrators as well as the Remote Desktop > Users groups, but the error message given at logon is "The requested > session access is denied.". The PAC (the part oh the Kerberos ticket which contains the SID of the user, his groupmemberships and other data) will contain the SIDs of the groups of the user on the IPA side not what is defined locally on the Windows machine. Maybe it might help if you add the user to a group on the IPA side which has the 'Domain Admins' SID, i.e. the IPA Domain SID + '-512'. If you have run ipa-adtrust-install the IPA admins group should already have this SID. HTH bye, Sumit > > There must be some way to get more information on what the system is > doing and what it wants. Perhaps it would be possible to increase the > amount of debugging information in the event viewer? Maybe it would > start working again if I flipped the right 0 to a 1 somewhere in the > deep registry forest... > > > Nicklas > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From isaev at fintech.ru Thu Nov 14 11:50:38 2013 From: isaev at fintech.ru (=?koi8-r?B?6dPBxdcg98nUwczJyiDhzsHUz8zYxdfJ3g==?=) Date: Thu, 14 Nov 2013 11:50:38 +0000 Subject: [Freeipa-users] IPA 4001 error while adding new user in WebUI after ACI configuration Message-ID: <69303615BE133645963548DD4A3BFCB3A706A7@E2K7.fintech.ru> Dear freeipa-users, We are diving deeper in RHEL IdM and facing with new issues. Several days ago we started to learn ACI following the advices of Martin Kosek and Rob Crittenden. The attached Python script with variables stored in "admins" file reconstruct the customized configuration of the ACI on our IdM server. Afterwards what we are trying to do is: 1. Logging into the IdM WebUI as one of the newly created minor admins (from "admins" file) 2. Trying to add any user (Identity -> Users -> User Add) The results of this sequence of actions are: 1. Web-UI message box with text: "IPA Error 4001: no such entry" 2. /var/log/httpd/error_log: [...date time...] [error] ipa: INFO: g1admin at DEV.RU: user_add(u'test_user', givenname=u'name', sn=u'surname'): NotFound 3. Finally - and we are perplexed with that - we recognize that the desired user has been successfully added to IdM. We would be very grateful if someone was able to reproduce this problem. Vitaly Isaev -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: admins Type: application/octet-stream Size: 296 bytes Desc: admins URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa.py Type: application/octet-stream Size: 3691 bytes Desc: freeipa.py URL: From david.kreuter at bytesource.net Thu Nov 14 12:14:34 2013 From: david.kreuter at bytesource.net (David Kreuter) Date: Thu, 14 Nov 2013 13:14:34 +0100 (CET) Subject: [Freeipa-users] Sudo rule still working after deactivation In-Reply-To: Message-ID: <1f1e92ee-baf5-45f5-b115-028dba6305f8@zimbra.bytesource.net> Thanks for the fast reply and great support. The usage of 'entry_cache_sudo_timeout' parameter does the trick. From rcritten at redhat.com Thu Nov 14 13:56:52 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 14 Nov 2013 08:56:52 -0500 Subject: [Freeipa-users] Installation issues with sub-ca. In-Reply-To: <1383360113.57557.1384417775122.JavaMail.root@dbmsrl.com> References: <1008786015.35062.1383756329711.JavaMail.root@dbmsrl.com> <1138098293.38547.1383827961817.JavaMail.root@dbmsrl.com> <527BA94A.9010400@redhat.com> <1824702199.51976.1384268218544.JavaMail.root@dbmsrl.com> <5282590A.2030500@redhat.com> <52826731.7020502@redhat.com> <638724550.54180.1384340083404.JavaMail.root@dbmsrl.com> <5283C056.9060006@redhat.com> <1383360113.57557.1384417775122.JavaMail.root@dbmsrl.com> Message-ID: <5284D6A4.3080901@redhat.com> Andrea Bontempi wrote: >> This is incorrect. To validate a certificate you only need the CA public >> keys, not the private ones. Only having the ipa-ca-agent key is right. >> This is a temporary database, not the CA database. We are using this >> cert to request some information about itself from the CA in this case. > > You're right, I thought that the script use a temporary db to create the final database, but it's only to connect with sslget. > >> I think there is an issue with one of the CA certs but I've yet to >> duplicate it or identify what is wrong. I'm still waiting on word back >> from one of the NSS devs. > > > I did some tests: The error occurs when I use a CA managed by EJBCA, if I use a CA generated by openssl or nss everything works properly. > > The problem is that i can't reproduce the bug in an external nss db... but maybe I don't follow the same steps that uses the installation script. The problem has to do with the encoding of the subject and issuer fields. The issue is one is encoded as a UTF8 string and the other is encoded as a printable string. This makes the binary derSubject and derIssuer fields different. NSS does not like derSubject and derIssuer fields that are different Server's raw der issuer: v 30 35 31 13 30 11 06 03 02 05 04 10 55 04 0a 13 < Note the 0x13->0x0c change here 0a 44 42 4d 53 52 4c 2e 43 4f 4d 31 1e 30 1c 06 03 02 05 04 03 55 04 03 13 15 43 65 72 74 69 66 69 63 61 74 65 20 41 75 74 68 6f 72 69 74 79 Issuer's raw der subject: V 30 35 31 13 30 11 06 03 02 05 04 10 55 04 0a 0c < 0a 44 42 4d 53 52 4c 2e 43 4f 4d 31 1e 30 1c 06 03 02 05 04 03 55 04 03 0c 15 43 65 72 74 69 66 69 63 61 74 65 20 41 75 74 68 6f 72 69 74 79 The NSS dev suggested issuing a new intermediate certificate using a Printable String for the the subject and everything else is the same. The problem is that this intermediate cert is issued by dogtag and I'm not sure if we have that level of control. You can't restart a failed install, and if you try it again you'll end up with the same problem. I've cc'd a dogtag developer to see if this can be handled via the profiles that dogtag uses to generate certificates. rob From jdennis at redhat.com Thu Nov 14 14:39:15 2013 From: jdennis at redhat.com (John Dennis) Date: Thu, 14 Nov 2013 09:39:15 -0500 Subject: [Freeipa-users] Installation issues with sub-ca. In-Reply-To: <1383360113.57557.1384417775122.JavaMail.root@dbmsrl.com> References: <1008786015.35062.1383756329711.JavaMail.root@dbmsrl.com> <1138098293.38547.1383827961817.JavaMail.root@dbmsrl.com> <527BA94A.9010400@redhat.com> <1824702199.51976.1384268218544.JavaMail.root@dbmsrl.com> <5282590A.2030500@redhat.com> <52826731.7020502@redhat.com> <638724550.54180.1384340083404.JavaMail.root@dbmsrl.com> <5283C056.9060006@redhat.com> <1383360113.57557.1384417775122.JavaMail.root@dbmsrl.com> Message-ID: <5284E093.3060700@redhat.com> On 11/14/2013 03:29 AM, Andrea Bontempi wrote: > I did some tests: The error occurs when I use a CA managed by EJBCA, > if I use a CA generated by openssl or nss everything works properly. > > The problem is that i can't reproduce the bug in an external nss > db... but maybe I don't follow the same steps that uses the > installation script. Do we have a copy of the sub-CA cert and the CA cert which we can examine? There are a variety of rules (primarially in the cert extentions) which can cause validation failure if the extensions are not as expected. My guess is you've got something specified in the extensions which is unanticiapated or incorrect. -- John From jdennis at redhat.com Thu Nov 14 14:45:26 2013 From: jdennis at redhat.com (John Dennis) Date: Thu, 14 Nov 2013 09:45:26 -0500 Subject: [Freeipa-users] Installation issues with sub-ca. In-Reply-To: <5284D6A4.3080901@redhat.com> References: <1008786015.35062.1383756329711.JavaMail.root@dbmsrl.com> <1138098293.38547.1383827961817.JavaMail.root@dbmsrl.com> <527BA94A.9010400@redhat.com> <1824702199.51976.1384268218544.JavaMail.root@dbmsrl.com> <5282590A.2030500@redhat.com> <52826731.7020502@redhat.com> <638724550.54180.1384340083404.JavaMail.root@dbmsrl.com> <5283C056.9060006@redhat.com> <1383360113.57557.1384417775122.JavaMail.root@dbmsrl.com> <5284D6A4.3080901@redhat.com> Message-ID: <5284E206.1000001@redhat.com> On 11/14/2013 08:56 AM, Rob Crittenden wrote: > Andrea Bontempi wrote: >>> This is incorrect. To validate a certificate you only need the CA public >>> keys, not the private ones. Only having the ipa-ca-agent key is right. >>> This is a temporary database, not the CA database. We are using this >>> cert to request some information about itself from the CA in this case. >> >> You're right, I thought that the script use a temporary db to create the final database, but it's only to connect with sslget. >> >>> I think there is an issue with one of the CA certs but I've yet to >>> duplicate it or identify what is wrong. I'm still waiting on word back >>> from one of the NSS devs. >> >> >> I did some tests: The error occurs when I use a CA managed by EJBCA, if I use a CA generated by openssl or nss everything works properly. >> >> The problem is that i can't reproduce the bug in an external nss db... but maybe I don't follow the same steps that uses the installation script. > > The problem has to do with the encoding of the subject and issuer fields. > > The issue is one is encoded as a UTF8 string and the other is > encoded as a printable string. This makes the binary derSubject and > derIssuer fields different. NSS does not like derSubject and derIssuer > fields that are different Good information! But this sounds like a bug to me if NSS is comparing binary data for equality, one should decode the binary encoding to arrive at a canonical form and then compare the canonical form, right? -- John From abontempi at dbmsrl.com Thu Nov 14 15:07:52 2013 From: abontempi at dbmsrl.com (Andrea Bontempi) Date: Thu, 14 Nov 2013 16:07:52 +0100 (CET) Subject: [Freeipa-users] Installation issues with sub-ca. In-Reply-To: <5284D6A4.3080901@redhat.com> References: <1008786015.35062.1383756329711.JavaMail.root@dbmsrl.com> <1824702199.51976.1384268218544.JavaMail.root@dbmsrl.com> <5282590A.2030500@redhat.com> <52826731.7020502@redhat.com> <638724550.54180.1384340083404.JavaMail.root@dbmsrl.com> <5283C056.9060006@redhat.com> <1383360113.57557.1384417775122.JavaMail.root@dbmsrl.com> <5284D6A4.3080901@redhat.com> Message-ID: <16999319.59640.1384441672487.JavaMail.root@dbmsrl.com> > The issue is one is encoded as a UTF8 string and the other is > encoded as a printable string. This makes the binary derSubject and > derIssuer fields different. NSS does not like derSubject and derIssuer > fields that are different Wow, that was the problem! Now it works! To fix must go to EJBCA Administration and activate "PrintableString encoding in DN" option in a new CA. Thank you very much, your help has been fundamental :-) Andrea Bontempi From abontempi at dbmsrl.com Fri Nov 15 09:50:28 2013 From: abontempi at dbmsrl.com (Andrea Bontempi) Date: Fri, 15 Nov 2013 10:50:28 +0100 (CET) Subject: [Freeipa-users] Installation issues with sub-ca. [SOLVED] In-Reply-To: <5284F6CE.4010405@redhat.com> References: <1008786015.35062.1383756329711.JavaMail.root@dbmsrl.com> <52826731.7020502@redhat.com> <638724550.54180.1384340083404.JavaMail.root@dbmsrl.com> <5283C056.9060006@redhat.com> <1383360113.57557.1384417775122.JavaMail.root@dbmsrl.com> <5284D6A4.3080901@redhat.com> <16999319.59640.1384441672487.JavaMail.root@dbmsrl.com> <5284F6CE.4010405@redhat.com> Message-ID: <646102368.61566.1384509028939.JavaMail.root@dbmsrl.com> The problem is the encoding of the certificate subject, some CA use UTF-8 (like EJBCA), contrariwise NSS create certificates with subject in ASCII. The error occurs during the installation on the step "issuing RA agent certificate", when sslget try to use the TLS certificate "ipa-ca-agent" and fail with error code "-12195". This error (SSL_ERROR_UNKNOWN_CA_ALERT) means that "ipa-ca-agent" is signed by a missing CA. If you open the NSS database used by sslget you can see the correct CA chain, but you can't follow this chain from "ipa-ca-agent", this is the cause of the error explained above. NSS for follow the chain make a bit-to-bit compare to the derSubject and derIssuer fields, but can't match because one is in UTF-8 and other is in ASCII. For fix, you must use the old mode (PrintableString) for sign the FreeIPA sub-ca certificate, in EJBCA just make a new root CA with the option "PrintableString encoding in DN" enabled. Thanks for the help. Andrea Bontempi From tsoucy at salesforce.com Wed Nov 20 19:37:21 2013 From: tsoucy at salesforce.com (Terry Soucy) Date: Wed, 20 Nov 2013 15:37:21 -0400 Subject: [Freeipa-users] out of sync replicas Message-ID: I am currently having the following issue. Running Redhat IPA on RHEL6.3 (ipa-server-3.0.0.25) in a basic two server multimaster setup. Servers A is running fine, but Server B is out of sync. More specifically, the ldap service principal is out of sync between the two servers, which is leading to no replication, etc, etc. I need to sync the ldap/serverB service principal on Server A with the ldap/serverB service principal on Server B. Is there a way to do that, or am I looking at a re-init of server B? Terry -- Terry Soucy - Systems Engineer Salesforce MarketingCloud - http://www.salesforce.com (o) 506.631.7445 (c) 506.609.3247 | (e) tsoucy at salesforce.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Wed Nov 20 19:56:19 2013 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 20 Nov 2013 12:56:19 -0700 Subject: [Freeipa-users] out of sync replicas In-Reply-To: References: Message-ID: <528D13E3.4010002@redhat.com> On 11/20/2013 12:37 PM, Terry Soucy wrote: > I am currently having the following issue. > > Running Redhat IPA on RHEL6.3 (ipa-server-3.0.0.25) in a basic two > server multimaster setup. > > Servers A is running fine, but Server B is out of sync. More > specifically, the ldap service principal is out of sync between the > two servers, which is leading to no replication, etc, etc. I need to > sync the ldap/serverB service principal on Server A with the > ldap/serverB service principal on Server B. Is there a way to do that, > or am I looking at a re-init of server B? I'm not sure what you mean by "the ldap service principal is out of sync between the two servers"? > > Terry > > -- > Terry Soucy - Systems Engineer > Salesforce MarketingCloud - http://www.salesforce.com > (o) 506.631.7445 (c) 506.609.3247 | (e) tsoucy at salesforce.com > > > > _______________________________________________ > 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 tsoucy at salesforce.com Wed Nov 20 20:05:46 2013 From: tsoucy at salesforce.com (Terry Soucy) Date: Wed, 20 Nov 2013 16:05:46 -0400 Subject: [Freeipa-users] out of sync replicas In-Reply-To: <528D13E3.4010002@redhat.com> References: <528D13E3.4010002@redhat.com> Message-ID: The service principal ldap/serverB was exported but not put into place at /etc/dirsrv/ds.keytab. Replication started failing, dns couldn't connect, the work generally started coming to an end. I've re-exported the service principal to a keytab file. If I export from serverA using the ipa-getkeytab file, I get one version number. If I export from server B, I get an older version number. When I use the kvno command, I get an even older number. Terry On Wed, Nov 20, 2013 at 3:56 PM, Rich Megginson wrote: > On 11/20/2013 12:37 PM, Terry Soucy wrote: > > I am currently having the following issue. > > Running Redhat IPA on RHEL6.3 (ipa-server-3.0.0.25) in a basic two > server multimaster setup. > > Servers A is running fine, but Server B is out of sync. More > specifically, the ldap service principal is out of sync between the two > servers, which is leading to no replication, etc, etc. I need to sync the > ldap/serverB service principal on Server A with the ldap/serverB service > principal on Server B. Is there a way to do that, or am I looking at a > re-init of server B? > > > I'm not sure what you mean by "the ldap service principal is out of sync > between the two servers"? > > > Terry > > -- > Terry Soucy - Systems Engineer > Salesforce MarketingCloud - http://www.salesforce.com > (o) 506.631.7445 (c) 506.609.3247 | (e) tsoucy at salesforce.com > > > _______________________________________________ > Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users > > > -- Terry Soucy - Systems Engineer Salesforce MarketingCloud - http://www.salesforce.com (o) 506.631.7445 (c) 506.609.3247 | (e) tsoucy at salesforce.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From tsoucy at salesforce.com Wed Nov 20 20:06:43 2013 From: tsoucy at salesforce.com (Terry Soucy) Date: Wed, 20 Nov 2013 16:06:43 -0400 Subject: [Freeipa-users] out of sync replicas In-Reply-To: References: <528D13E3.4010002@redhat.com> Message-ID: I have the keytab with the oldest version number shown in the kvno command, but when I put that into place, I get no joy. Terry On Wed, Nov 20, 2013 at 4:05 PM, Terry Soucy wrote: > The service principal ldap/serverB was exported but not put into place at > /etc/dirsrv/ds.keytab. Replication started failing, dns couldn't connect, > the work generally started coming to an end. I've re-exported the service > principal to a keytab file. If I export from serverA using the > ipa-getkeytab file, I get one version number. If I export from server B, I > get an older version number. When I use the kvno command, I get an even > older number. > > Terry > > > On Wed, Nov 20, 2013 at 3:56 PM, Rich Megginson wrote: > >> On 11/20/2013 12:37 PM, Terry Soucy wrote: >> >> I am currently having the following issue. >> >> Running Redhat IPA on RHEL6.3 (ipa-server-3.0.0.25) in a basic two >> server multimaster setup. >> >> Servers A is running fine, but Server B is out of sync. More >> specifically, the ldap service principal is out of sync between the two >> servers, which is leading to no replication, etc, etc. I need to sync the >> ldap/serverB service principal on Server A with the ldap/serverB service >> principal on Server B. Is there a way to do that, or am I looking at a >> re-init of server B? >> >> >> I'm not sure what you mean by "the ldap service principal is out of sync >> between the two servers"? >> >> >> Terry >> >> -- >> Terry Soucy - Systems Engineer >> Salesforce MarketingCloud - http://www.salesforce.com >> (o) 506.631.7445 (c) 506.609.3247 | (e) tsoucy at salesforce.com >> >> >> _______________________________________________ >> Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users >> >> >> > > > -- > Terry Soucy - Systems Engineer > Salesforce MarketingCloud - http://www.salesforce.com > (o) 506.631.7445 (c) 506.609.3247 | (e) tsoucy at salesforce.com > -- Terry Soucy - Systems Engineer Salesforce MarketingCloud - http://www.salesforce.com (o) 506.631.7445 (c) 506.609.3247 | (e) tsoucy at salesforce.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Wed Nov 20 20:10:37 2013 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 20 Nov 2013 13:10:37 -0700 Subject: [Freeipa-users] out of sync replicas In-Reply-To: References: <528D13E3.4010002@redhat.com> Message-ID: <528D173D.5070905@redhat.com> On 11/20/2013 01:06 PM, Terry Soucy wrote: > I have the keytab with the oldest version number shown in the kvno > command, but when I put that into place, I get no joy. I don't know. Perhaps someone with ipa kerberos expertise can help. > > Terry > > > On Wed, Nov 20, 2013 at 4:05 PM, Terry Soucy > wrote: > > The service principal ldap/serverB was exported but not put into > place at /etc/dirsrv/ds.keytab. Replication started failing, dns > couldn't connect, the work generally started coming to an end. > I've re-exported the service principal to a keytab file. If I > export from serverA using the ipa-getkeytab file, I get one > version number. If I export from server B, I get an older version > number. When I use the kvno command, I get an even older number. > > Terry > > > On Wed, Nov 20, 2013 at 3:56 PM, Rich Megginson > > wrote: > > On 11/20/2013 12:37 PM, Terry Soucy wrote: >> I am currently having the following issue. >> >> Running Redhat IPA on RHEL6.3 (ipa-server-3.0.0.25) in a >> basic two server multimaster setup. >> >> Servers A is running fine, but Server B is out of sync. More >> specifically, the ldap service principal is out of sync >> between the two servers, which is leading to no replication, >> etc, etc. I need to sync the ldap/serverB service principal >> on Server A with the ldap/serverB service principal on Server >> B. Is there a way to do that, or am I looking at a re-init of >> server B? > > I'm not sure what you mean by "the ldap service principal is > out of sync between the two servers"? > >> >> Terry >> >> -- >> Terry Soucy - Systems Engineer >> Salesforce MarketingCloud - http://www.salesforce.com >> (o) 506.631.7445 (c) 506.609.3247 >> | (e) tsoucy at salesforce.com >> >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > -- > Terry Soucy - Systems Engineer > Salesforce MarketingCloud - http://www.salesforce.com > (o) 506.631.7445 (c) 506.609.3247 > | (e) tsoucy at salesforce.com > > > > > > -- > Terry Soucy - Systems Engineer > Salesforce MarketingCloud - http://www.salesforce.com > (o) 506.631.7445 (c) 506.609.3247 | (e) tsoucy at salesforce.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steven.Jones at vuw.ac.nz Wed Nov 20 20:11:31 2013 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Wed, 20 Nov 2013 20:11:31 +0000 Subject: [Freeipa-users] out of sync replicas In-Reply-To: References: Message-ID: <833D8E48405E064EBC54C84EC6B36E407FB4CBA4@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, 6.4 is a lot more stable than 6.3 so make an update a priority IMHO. Not 100% sure what you mean but if they simply are out of sync then, 2 ways, (make a full ldap2file backup first). 1) un-install IPA server on B, reboot and re-install on B. 2) You can force a re-sync at the command line, worth a shot. Sometimes though this doesnt work and you need to do a huge clearing out. I'd almost suggest blow away B, upgrade A to 6.4 and upgrade B to 6.4 and re-install on B. I found loss of sync on 6.3 a common and frequent occurrence, IPA on 6.4 seems way better in just about every way. regards Steven Jones Technical Specialist - Linux RHCE Victoria University ITS, Level 8 Rankin Brown Building, Wellington, NZ 6012 0064 4 463 6272 ________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Terry Soucy [tsoucy at salesforce.com] Sent: Thursday, 21 November 2013 8:37 a.m. To: freeipa-users at redhat.com Subject: [Freeipa-users] out of sync replicas I am currently having the following issue. Running Redhat IPA on RHEL6.3 (ipa-server-3.0.0.25) in a basic two server multimaster setup. Servers A is running fine, but Server B is out of sync. More specifically, the ldap service principal is out of sync between the two servers, which is leading to no replication, etc, etc. I need to sync the ldap/serverB service principal on Server A with the ldap/serverB service principal on Server B. Is there a way to do that, or am I looking at a re-init of server B? Terry -- Terry Soucy - Systems Engineer Salesforce MarketingCloud - http://www.salesforce.com (o) 506.631.7445 (c) 506.609.3247 | (e) tsoucy at salesforce.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Wed Nov 20 20:21:03 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 20 Nov 2013 15:21:03 -0500 Subject: [Freeipa-users] out of sync replicas In-Reply-To: References: <528D13E3.4010002@redhat.com> Message-ID: <528D19AF.6090709@redhat.com> Terry Soucy wrote: > I have the keytab with the oldest version number shown in the kvno > command, but when I put that into place, I get no joy. A lot more details are required. Did you change or renew the keytab? Did it suddenly stop working, and when? Logs? /var/log/dirsrv/slapd-REALM/error and access. /var/log/krb5kdc.log. rob > > Terry > > > On Wed, Nov 20, 2013 at 4:05 PM, Terry Soucy > wrote: > > The service principal ldap/serverB was exported but not put into > place at /etc/dirsrv/ds.keytab. Replication started failing, dns > couldn't connect, the work generally started coming to an end. I've > re-exported the service principal to a keytab file. If I export from > serverA using the ipa-getkeytab file, I get one version number. If I > export from server B, I get an older version number. When I use the > kvno command, I get an even older number. > > Terry > > > On Wed, Nov 20, 2013 at 3:56 PM, Rich Megginson > wrote: > > On 11/20/2013 12:37 PM, Terry Soucy wrote: >> I am currently having the following issue. >> >> Running Redhat IPA on RHEL6.3 (ipa-server-3.0.0.25) in a basic >> two server multimaster setup. >> >> Servers A is running fine, but Server B is out of sync. More >> specifically, the ldap service principal is out of sync >> between the two servers, which is leading to no replication, >> etc, etc. I need to sync the ldap/serverB service principal on >> Server A with the ldap/serverB service principal on Server B. >> Is there a way to do that, or am I looking at a re-init of >> server B? > > I'm not sure what you mean by "the ldap service principal is out > of sync between the two servers"? > >> >> Terry >> >> -- >> Terry Soucy - Systems Engineer >> Salesforce MarketingCloud - http://www.salesforce.com >> (o) 506.631.7445 (c) 506.609.3247 >> | (e) tsoucy at salesforce.com >> >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > -- > Terry Soucy - Systems Engineer > Salesforce MarketingCloud - http://www.salesforce.com > (o) 506.631.7445 (c) 506.609.3247 > | (e) tsoucy at salesforce.com > > > > > > -- > Terry Soucy - Systems Engineer > Salesforce MarketingCloud - http://www.salesforce.com > (o) 506.631.7445 (c) 506.609.3247 | (e) tsoucy at salesforce.com > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > From tsoucy at salesforce.com Wed Nov 20 20:32:37 2013 From: tsoucy at salesforce.com (Terry Soucy) Date: Wed, 20 Nov 2013 16:32:37 -0400 Subject: [Freeipa-users] out of sync replicas In-Reply-To: <528D19AF.6090709@redhat.com> References: <528D13E3.4010002@redhat.com> <528D19AF.6090709@redhat.com> Message-ID: The ldap/serverB keytab was renewed with the ipa-getkeytab command, but not put into place. Since the existing keytab in /etc/dirsrv/ds.keytab was no longer valid, replication stopped. I've since exported it a couple more times from each of the servers in an attempt to get it working again, but none of the keytabs work. I can, however, auth to the kerberos server using the latest keytab file using kinit -kt /etc/dirsrv/ds.keytab ldap/serverB. I've verified permissions on the keytab file. Now, when I attempt to start replication, it gives me this in the error log ... [20/Nov/2013:16:29:40 -0400] set_krb5_creds - Could not get initial credentials for principal [ldap/en5013.dev.ca1.sfmc.co at SFMC.CO] in keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328174 (Generic preauthentication failure) [20/Nov/2013:16:29:40 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credentials cache file '/tmp/krb5cc_497' not found)) errno 0 (Success) [20/Nov/2013:16:29:40 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error -2 (Local error) [20/Nov/2013:16:29:40 -0400] NSMMReplicationPlugin - agmt="cn= meTodv5002-en1.dev.ca1.sfmc.co" (dv5002-en1:389): Replication bind with GSSAPI auth failed: LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credentials cache file '/tmp/krb5cc_497' not found)) Over and over and over again. I can auth to the server with a standard bind, but GSSAPI auth will not function. I've even attempted to su to the dirsrv user and run a kinit using the ds.keytab file and setting the cache to /tmp/krb5cc_497, but it just compplains that the permissions on the cache credentials file are incorrect. I've also attempted to remove the replica from the working server, but I get an authentication error when it attempts to contact the non-functional server .. # ipa-replica-manage del en5013.dev.ca1.sfmc.co Connection to 'en5013.dev.ca1.sfmc.co' failed: Invalid credentials SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Unknown error) Unable to delete replica 'en5013.dev.ca1.sfmc.co' Terry On Wed, Nov 20, 2013 at 4:21 PM, Rob Crittenden wrote: > Terry Soucy wrote: > >> I have the keytab with the oldest version number shown in the kvno >> command, but when I put that into place, I get no joy. >> > > A lot more details are required. Did you change or renew the keytab? Did > it suddenly stop working, and when? > > Logs? /var/log/dirsrv/slapd-REALM/error and access. /var/log/krb5kdc.log. > > rob > > >> Terry >> >> >> On Wed, Nov 20, 2013 at 4:05 PM, Terry Soucy > > wrote: >> >> The service principal ldap/serverB was exported but not put into >> place at /etc/dirsrv/ds.keytab. Replication started failing, dns >> couldn't connect, the work generally started coming to an end. I've >> re-exported the service principal to a keytab file. If I export from >> serverA using the ipa-getkeytab file, I get one version number. If I >> export from server B, I get an older version number. When I use the >> kvno command, I get an even older number. >> >> Terry >> >> >> On Wed, Nov 20, 2013 at 3:56 PM, Rich Megginson > > wrote: >> >> On 11/20/2013 12:37 PM, Terry Soucy wrote: >> >>> I am currently having the following issue. >>> >>> Running Redhat IPA on RHEL6.3 (ipa-server-3.0.0.25) in a basic >>> two server multimaster setup. >>> >>> Servers A is running fine, but Server B is out of sync. More >>> specifically, the ldap service principal is out of sync >>> between the two servers, which is leading to no replication, >>> etc, etc. I need to sync the ldap/serverB service principal on >>> Server A with the ldap/serverB service principal on Server B. >>> Is there a way to do that, or am I looking at a re-init of >>> server B? >>> >> >> I'm not sure what you mean by "the ldap service principal is out >> of sync between the two servers"? >> >> >>> Terry >>> >>> -- >>> Terry Soucy - Systems Engineer >>> Salesforce MarketingCloud - http://www.salesforce.com >>> (o) 506.631.7445 (c) 506.609.3247 >>> | (e) tsoucy at salesforce.com >>> >>> >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> >> >> >> >> >> -- >> Terry Soucy - Systems Engineer >> Salesforce MarketingCloud - http://www.salesforce.com >> (o) 506.631.7445 (c) 506.609.3247 >> | (e) tsoucy at salesforce.com >> >> >> >> >> >> >> -- >> Terry Soucy - Systems Engineer >> Salesforce MarketingCloud - http://www.salesforce.com >> (o) 506.631.7445 (c) 506.609.3247 | (e) tsoucy at salesforce.com >> >> >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> > -- Terry Soucy - Systems Engineer Salesforce MarketingCloud - http://www.salesforce.com (o) 506.631.7445 (c) 506.609.3247 | (e) tsoucy at salesforce.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From sakodak at gmail.com Wed Nov 20 21:56:48 2013 From: sakodak at gmail.com (KodaK) Date: Wed, 20 Nov 2013 15:56:48 -0600 Subject: [Freeipa-users] Lesson learned: don't do this. Message-ID: Just wanted to pass along an issue I just had. We have some legacy local users on some boxes, and we need to have a mix of those local users and IPA users in the same groups. In order for that to happen (at least on AIX) I need to create a group in IPA with the GID of the local group. This can be a problem because the GID may be used by different groups on different boxes (we inherited this mess.) To organize this, I would create groups like this in IPA: host1-foogroup:208 host2-bargroup:208 host3-bazgroup:208 This worked, until I added a fourth group with the same GID. AIX stopped allowing members of 208 to connect to any hosts. I was forced to move them all into a single group and abandon my attempts at organization. This was hard to find, but obvious in retrospect. -- The government is going to read our mail anyway, might as well make it tough for them. GPG Public key ID: B6A1A7C6 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sakodak at gmail.com Wed Nov 20 22:00:40 2013 From: sakodak at gmail.com (KodaK) Date: Wed, 20 Nov 2013 16:00:40 -0600 Subject: [Freeipa-users] Revisiting ILO [SOLVED] Message-ID: Not exactly "solved" but I'll call it that, since there is no way to change the login attribute. I've requested this feature, but I requested it through support and I'm sure it will die in a queue somewhere. On Wed, Nov 6, 2013 at 6:25 AM, Dmitri Pal wrote: > On 11/05/2013 02:51 PM, KodaK wrote: > > If I use the whole connection string: > > uid=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com > > I can authenticate. > > > Does this count as SOLVED? > If so can you please reply with the SOLVED in the subject? > > > > On Tue, Nov 5, 2013 at 1:40 PM, KodaK wrote: > >> I'm attempting to get HP ILO authenticating against IPA again. >> >> I've configured the user context in ILO as: >> >> cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com >> >> When ILO tries to connect, it sends the string: >> >> CN=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com >> >> Which, of course, doesn't exist. IPA uses uid=, but as far >> as I can tell I can't tell ILO to use a different username attribute. It >> doesn't even look like it's trying to use a username attribute. >> >> I've tried to force it to look for uid=jebalicki by using >> "uid=jebalicki" in the login field, but that fails too. The errors in the >> errors log look like this: >> >> >> [05/Nov/2013:13:22:05 -0600] ipalockout_preop - [file ipa_lockout.c, >> line 645]: Failed to retrieve entry "jebalicki": 32 >> [05/Nov/2013:13:22:05 -0600] ipalockout_postop - [file ipa_lockout.c, >> line 421]: Failed to retrieve entry "jebalicki": 32 >> [05/Nov/2013:13:22:05 -0600] ipalockout_preop - [file ipa_lockout.c, line >> 645]: Failed to retrieve entry >> "CN=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com": 32 >> [05/Nov/2013:13:22:05 -0600] ipalockout_postop - [file ipa_lockout.c, >> line 421]: Failed to retrieve entry >> "CN=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com": 32 >> [05/Nov/2013:13:22:05 -0600] ipalockout_preop - [file ipa_lockout.c, line >> 645]: Failed to retrieve entry "jebalicki": 32 >> [05/Nov/2013:13:22:05 -0600] ipalockout_postop - [file ipa_lockout.c, >> line 421]: Failed to retrieve entry "jebalicki": 32 >> [05/Nov/2013:13:22:05 -0600] ipalockout_preop - [file ipa_lockout.c, line >> 645]: Failed to retrieve entry >> "CN=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com": 32 >> [05/Nov/2013:13:22:05 -0600] ipalockout_postop - [file ipa_lockout.c, >> line 421]: Failed to retrieve entry >> "CN=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com": 32 >> [05/Nov/2013:13:22:05 -0600] ipalockout_preop - [file ipa_lockout.c, line >> 645]: Failed to retrieve entry "jebalicki": 32 >> [05/Nov/2013:13:22:05 -0600] ipalockout_postop - [file ipa_lockout.c, >> line 421]: Failed to retrieve entry "jebalicki": 32 >> [05/Nov/2013:13:22:05 -0600] ipalockout_preop - [file ipa_lockout.c, line >> 645]: Failed to retrieve entry >> "CN=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com": 32 >> [05/Nov/2013:13:22:05 -0600] ipalockout_postop - [file ipa_lockout.c, >> line 421]: Failed to retrieve entry >> "CN=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com": 32 >> [05/Nov/2013:13:27:39 -0600] ipalockout_preop - [file ipa_lockout.c, line >> 645]: Failed to retrieve entry "uid=jebalicki": 32 >> [05/Nov/2013:13:27:39 -0600] ipalockout_postop - [file ipa_lockout.c, >> line 421]: Failed to retrieve entry "uid=jebalicki": 32 >> [05/Nov/2013:13:27:39 -0600] ipalockout_preop - [file ipa_lockout.c, line >> 645]: Failed to retrieve entry >> "CN=uid=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com": 32 >> [05/Nov/2013:13:27:39 -0600] ipalockout_postop - [file ipa_lockout.c, >> line 421]: Failed to retrieve entry >> "CN=uid=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com": 32 >> [05/Nov/2013:13:27:39 -0600] ipalockout_preop - [file ipa_lockout.c, line >> 645]: Failed to retrieve entry "uid=jebalicki": 32 >> [05/Nov/2013:13:27:39 -0600] ipalockout_postop - [file ipa_lockout.c, >> line 421]: Failed to retrieve entry "uid=jebalicki": 32 >> [05/Nov/2013:13:27:39 -0600] ipalockout_preop - [file ipa_lockout.c, line >> 645]: Failed to retrieve entry >> "CN=uid=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com": 32 >> [05/Nov/2013:13:27:39 -0600] ipalockout_postop - [file ipa_lockout.c, >> line 421]: Failed to retrieve entry >> "CN=uid=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com": 32 >> [05/Nov/2013:13:27:39 -0600] ipalockout_preop - [file ipa_lockout.c, line >> 645]: Failed to retrieve entry "uid=jebalicki": 32 >> [05/Nov/2013:13:27:39 -0600] ipalockout_postop - [file ipa_lockout.c, >> line 421]: Failed to retrieve entry "uid=jebalicki": 32 >> [05/Nov/2013:13:27:39 -0600] ipalockout_preop - [file ipa_lockout.c, line >> 645]: Failed to retrieve entry >> "CN=uid=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com": 32 >> [05/Nov/2013:13:27:39 -0600] ipalockout_postop - [file ipa_lockout.c, >> line 421]: Failed to retrieve entry >> "CN=uid=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com": 32 >> >> And the access log looks like this: >> >> [05/Nov/2013:13:32:06 -0600] conn=214941 fd=438 slot=438 SSL connection >> from 10.200.10.192 to 10.200.16.170 >> [05/Nov/2013:13:32:06 -0600] conn=214941 SSL 256-bit AES >> [05/Nov/2013:13:32:06 -0600] conn=214941 op=0 BIND dn="uid=jebalicki" >> method=128 version=2 >> [05/Nov/2013:13:32:06 -0600] conn=214941 op=0 RESULT err=32 tag=97 >> nentries=0 etime=0 >> [05/Nov/2013:13:32:06 -0600] conn=214941 op=1 BIND >> dn="CN=uid=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com" >> method=128 version=2 >> [05/Nov/2013:13:32:07 -0600] conn=214941 op=1 RESULT err=32 tag=97 >> nentries=0 etime=1 >> [05/Nov/2013:13:32:07 -0600] conn=214941 op=2 UNBIND >> [05/Nov/2013:13:32:07 -0600] conn=214941 op=2 fd=438 closed - U1 >> [05/Nov/2013:13:32:07 -0600] conn=214942 fd=439 slot=439 SSL connection >> from 10.200.10.192 to 10.200.16.170 >> [05/Nov/2013:13:32:07 -0600] conn=214942 SSL 256-bit AES >> [05/Nov/2013:13:32:07 -0600] conn=214942 op=0 BIND dn="uid=jebalicki" >> method=128 version=2 >> [05/Nov/2013:13:32:07 -0600] conn=214942 op=0 RESULT err=32 tag=97 >> nentries=0 etime=0 >> [05/Nov/2013:13:32:07 -0600] conn=214942 op=1 UNBIND >> [05/Nov/2013:13:32:07 -0600] conn=214942 op=1 fd=439 closed - U1 >> [05/Nov/2013:13:32:07 -0600] conn=214943 fd=438 slot=438 SSL connection >> from 10.200.10.192 to 10.200.16.170 >> [05/Nov/2013:13:32:07 -0600] conn=214943 SSL 256-bit AES >> [05/Nov/2013:13:32:07 -0600] conn=214943 op=0 BIND >> dn="CN=uid=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com" >> method=128 version=2 >> [05/Nov/2013:13:32:07 -0600] conn=214943 op=0 RESULT err=32 tag=97 >> nentries=0 etime=0 >> [05/Nov/2013:13:32:07 -0600] conn=214943 op=1 UNBIND >> [05/Nov/2013:13:32:07 -0600] conn=214943 op=1 fd=438 closed - U1 >> >> Is there any way to force things on the IPA side? Can I automatically >> attach on the necessary components to the provided username? >> >> > > > -- > The government is going to read our mail anyway, might as well make it > tough for them. GPG Public key ID: B6A1A7C6 > > > _______________________________________________ > 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 > -- The government is going to read our mail anyway, might as well make it tough for them. GPG Public key ID: B6A1A7C6 -------------- next part -------------- An HTML attachment was scrubbed... URL: From amessina at messinet.com Fri Nov 22 23:24:39 2013 From: amessina at messinet.com (Anthony Messina) Date: Fri, 22 Nov 2013 17:24:39 -0600 Subject: [Freeipa-users] Fedora 19 upgrading mod_nss Message-ID: <125925832.dEyFUjyyYc@linux-ws1.messinet.com> After pulling down a mod_nss upgrade, the nss.conf.rpmnew file has some additional content. The diff is below. Should I merge in the new NSSCipherSuite/NSSProtocol changes on an IPA system or leave it as is? [root at ipa1 ~]# diff -u /etc/httpd/conf.d/nss.conf /etc/httpd/conf.d/nss.conf.rpmnew --- /etc/httpd/conf.d/nss.conf 2013-10-06 11:58:57.297000000 -0500 +++ /etc/httpd/conf.d/nss.conf.rpmnew 2013-10-24 16:22:49.000000000 -0500 @@ -14,9 +14,9 @@ # standard HTTP port (see above) and to the HTTPS port # # Note: Configurations that use IPv6 but not IPv4-mapped addresses need two -# Listen directives: "Listen [::]:443" and "Listen 0.0.0.0:443" +# Listen directives: "Listen [::]:8443" and "Listen 0.0.0.0:443" # -Listen 443 +Listen 8443 ## ## SSL Global Context @@ -35,7 +35,7 @@ # Configure the pass phrase gathering process. # The filtering dialog program (`builtin' is a internal # terminal dialog) has to provide the pass phrase on stdout. -NSSPassPhraseDialog "file:/etc/httpd/conf/password.conf" +NSSPassPhraseDialog builtin # Pass Phrase Helper: @@ -73,21 +73,21 @@ # # Only renegotiate if the peer's hello bears the TLS renegotiation_info # extension. Default off. -NSSRenegotiation on +NSSRenegotiation off # Peer must send Signaling Cipher Suite Value (SCSV) or # Renegotiation Info (RI) extension in ALL handshakes. Default: off -NSSRequireSafeNegotiation on +NSSRequireSafeNegotiation off ## ## SSL Virtual Host Context ## - + # General setup for the virtual host #DocumentRoot "/etc/httpd/htdocs" -#ServerName www.example.com:443 +#ServerName www.example.com:8443 #ServerAdmin you at example.com # mod_nss can log to separate log files, you can choose to do that if you'd like @@ -113,7 +113,16 @@ # ECC enabled NSS and mod_nss and want to use Elliptical Curve Cryptography #NSSCipherSuite +rsa_rc4_128_md5,+rsa_rc4_128_sha,+rsa_3des_sha,- rsa_des_sha,-rsa_rc4_40_md5,-rsa_rc2_40_md5,-rsa_null_md5,-rsa_null_sha, +fips_3des_sha,-fips_des_sha,-fortezza,-fortezza_rc4_128_sha,-fortezza_null,- rsa_des_56_sha,-rsa_rc4_56_sha,+rsa_aes_128_sha,+rsa_aes_256_sha,- ecdh_ecdsa_null_sha,+ecdh_ecdsa_rc4_128_sha,+ecdh_ecdsa_3des_sha, +ecdh_ecdsa_aes_128_sha,+ecdh_ecdsa_aes_256_sha,-ecdhe_ecdsa_null_sha, +ecdhe_ecdsa_rc4_128_sha,+ecdhe_ecdsa_3des_sha,+ecdhe_ecdsa_aes_128_sha, +ecdhe_ecdsa_aes_256_sha,-ecdh_rsa_null_sha,+ecdh_rsa_128_sha, +ecdh_rsa_3des_sha,+ecdh_rsa_aes_128_sha,+ecdh_rsa_aes_256_sha,- echde_rsa_null,+ecdhe_rsa_rc4_128_sha,+ecdhe_rsa_3des_sha, +ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_sha -NSSProtocol SSLv3,TLSv1 +# SSL Protocol: +# Cryptographic protocols that provide communication security. +# NSS handles the specified protocols as "ranges", and automatically +# negotiates the use of the strongest protocol for a connection starting +# with the maximum specified protocol and downgrading as necessary to the +# minimum specified protocol that can be used between two processes. +# Since all protocol ranges are completely inclusive, and no protocol in the +# middle of a range may be excluded, the entry "NSSProtocol SSLv3,TLSv1.1" +# is identical to the entry "NSSProtocol SSLv3,TLSv1.0,TLSv1.1". +NSSProtocol SSLv3,TLSv1.0,TLSv1.1 # SSL Certificate Nickname: # The nickname of the RSA server certificate you are going to use. @@ -214,6 +223,5 @@ #CustomLog /home/rcrit/redhat/apache/logs/ssl_request_log \ # "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b" -Include conf.d/ipa-rewrite.conf -- Anthony - http://messinet.com - http://messinet.com/~amessina/gallery 8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E -------------- 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 simo at redhat.com Sat Nov 23 03:28:33 2013 From: simo at redhat.com (Simo Sorce) Date: Fri, 22 Nov 2013 22:28:33 -0500 Subject: [Freeipa-users] Fedora 19 upgrading mod_nss In-Reply-To: <125925832.dEyFUjyyYc@linux-ws1.messinet.com> References: <125925832.dEyFUjyyYc@linux-ws1.messinet.com> Message-ID: <1385177313.22025.6.camel@willson.li.ssimo.org> On Fri, 2013-11-22 at 17:24 -0600, Anthony Messina wrote: > After pulling down a mod_nss upgrade, the nss.conf.rpmnew file has some > additional content. The diff is below. Should I merge in the new > NSSCipherSuite/NSSProtocol changes on an IPA system or leave it as is? It is probably a good idea to merge them in although IPA is not yet able to create EC based certs. The protocol is certainly worth it. Simo. > [root at ipa1 ~]# diff -u /etc/httpd/conf.d/nss.conf > /etc/httpd/conf.d/nss.conf.rpmnew > --- /etc/httpd/conf.d/nss.conf 2013-10-06 11:58:57.297000000 -0500 > +++ /etc/httpd/conf.d/nss.conf.rpmnew 2013-10-24 16:22:49.000000000 -0500 > @@ -14,9 +14,9 @@ > # standard HTTP port (see above) and to the HTTPS port > # > # Note: Configurations that use IPv6 but not IPv4-mapped addresses need two > -# Listen directives: "Listen [::]:443" and "Listen 0.0.0.0:443" > +# Listen directives: "Listen [::]:8443" and "Listen 0.0.0.0:443" > # > -Listen 443 > +Listen 8443 > > ## > ## SSL Global Context > @@ -35,7 +35,7 @@ > # Configure the pass phrase gathering process. > # The filtering dialog program (`builtin' is a internal > # terminal dialog) has to provide the pass phrase on stdout. > -NSSPassPhraseDialog "file:/etc/httpd/conf/password.conf" > +NSSPassPhraseDialog builtin > > > # Pass Phrase Helper: > @@ -73,21 +73,21 @@ > # > # Only renegotiate if the peer's hello bears the TLS renegotiation_info > # extension. Default off. > -NSSRenegotiation on > +NSSRenegotiation off > > # Peer must send Signaling Cipher Suite Value (SCSV) or > # Renegotiation Info (RI) extension in ALL handshakes. Default: off > -NSSRequireSafeNegotiation on > +NSSRequireSafeNegotiation off > > ## > ## SSL Virtual Host Context > ## > > - > + > > # General setup for the virtual host > #DocumentRoot "/etc/httpd/htdocs" > -#ServerName www.example.com:443 > +#ServerName www.example.com:8443 > #ServerAdmin you at example.com > > # mod_nss can log to separate log files, you can choose to do that if you'd > like > @@ -113,7 +113,16 @@ > # ECC enabled NSS and mod_nss and want to use Elliptical Curve Cryptography > #NSSCipherSuite +rsa_rc4_128_md5,+rsa_rc4_128_sha,+rsa_3des_sha,- > rsa_des_sha,-rsa_rc4_40_md5,-rsa_rc2_40_md5,-rsa_null_md5,-rsa_null_sha, > +fips_3des_sha,-fips_des_sha,-fortezza,-fortezza_rc4_128_sha,-fortezza_null,- > rsa_des_56_sha,-rsa_rc4_56_sha,+rsa_aes_128_sha,+rsa_aes_256_sha,- > ecdh_ecdsa_null_sha,+ecdh_ecdsa_rc4_128_sha,+ecdh_ecdsa_3des_sha, > +ecdh_ecdsa_aes_128_sha,+ecdh_ecdsa_aes_256_sha,-ecdhe_ecdsa_null_sha, > +ecdhe_ecdsa_rc4_128_sha,+ecdhe_ecdsa_3des_sha,+ecdhe_ecdsa_aes_128_sha, > +ecdhe_ecdsa_aes_256_sha,-ecdh_rsa_null_sha,+ecdh_rsa_128_sha, > +ecdh_rsa_3des_sha,+ecdh_rsa_aes_128_sha,+ecdh_rsa_aes_256_sha,- > echde_rsa_null,+ecdhe_rsa_rc4_128_sha,+ecdhe_rsa_3des_sha, > +ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_sha > > -NSSProtocol SSLv3,TLSv1 > +# SSL Protocol: > +# Cryptographic protocols that provide communication security. > +# NSS handles the specified protocols as "ranges", and automatically > +# negotiates the use of the strongest protocol for a connection starting > +# with the maximum specified protocol and downgrading as necessary to the > +# minimum specified protocol that can be used between two processes. > +# Since all protocol ranges are completely inclusive, and no protocol in > the > +# middle of a range may be excluded, the entry "NSSProtocol SSLv3,TLSv1.1" > +# is identical to the entry "NSSProtocol SSLv3,TLSv1.0,TLSv1.1". > +NSSProtocol SSLv3,TLSv1.0,TLSv1.1 > > # SSL Certificate Nickname: > # The nickname of the RSA server certificate you are going to use. > @@ -214,6 +223,5 @@ > #CustomLog /home/rcrit/redhat/apache/logs/ssl_request_log \ > # "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b" > > -Include conf.d/ipa-rewrite.conf > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Simo Sorce * Red Hat, Inc * New York From amessina at messinet.com Sat Nov 23 21:04:05 2013 From: amessina at messinet.com (Anthony Messina) Date: Sat, 23 Nov 2013 15:04:05 -0600 Subject: [Freeipa-users] Fedora 19 upgrading mod_nss In-Reply-To: <1385177313.22025.6.camel@willson.li.ssimo.org> References: <125925832.dEyFUjyyYc@linux-ws1.messinet.com> <1385177313.22025.6.camel@willson.li.ssimo.org> Message-ID: <2721573.lCTTzzzdyT@linux-ws1.messinet.com> On Friday, November 22, 2013 10:28:33 PM Simo Sorce wrote: > On Fri, 2013-11-22 at 17:24 -0600, Anthony Messina wrote: > > After pulling down a mod_nss upgrade, the nss.conf.rpmnew file has some > > additional content. The diff is below. Should I merge in the new > > NSSCipherSuite/NSSProtocol changes on an IPA system or leave it as is? > > It is probably a good idea to merge them in although IPA is not yet able > to create EC based certs. The protocol is certainly worth it. > > Simo. Ok, Simo. Thanks. -A -- Anthony - http://messinet.com - http://messinet.com/~amessina/gallery 8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E -------------- 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 matthew.bryant at melbourneit.com.au Sun Nov 24 23:23:22 2013 From: matthew.bryant at melbourneit.com.au (Matt Bryant) Date: Mon, 25 Nov 2013 09:23:22 +1000 Subject: [Freeipa-users] Intermittent Issues changing passwords since updating to ipa v3 and sasl_bind timeouts .. Message-ID: <52928A6A.9000802@melbourneit.com.au> All, Was wondering if anyone can help out or point us the in right direction. Ever since we updated from IPA v2.1 to IPA v3.0 have been seeing some intermittent errors when trying to change passwords etc. Getting the error cannot change password since system offline. Have increased the logging and found that quite frequently the sasl_bind using the host principle is timing out and failing ... (whether this is red herring or not dont know but cant be good anyhow) (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] [sdap_kinit_send] (0x0400): Attempting kinit (default, host/tardis.ipa.server-noc.com, SERVER-IPA, 86400) (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] [sdap_kinit_next_kdc] (0x1000): Resolving next KDC for service IPA (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] [get_server_status] (0x1000): Status of server 'tardis.ipa.server-noc.com' is 'working' (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] [fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set to 10 seconds (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] [get_server_status] (0x1000): Status of server 'tardis.ipa.server-noc.com' is 'working' (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] [be_resolve_server_process] (0x1000): Saving the first resolved server (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] [be_resolve_server_process] (0x0200): Found address for server tardis.ipa.server-noc.com: [203.147.190.30] TTL 7200 (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] [sdap_kinit_kdc_resolved] (0x1000): KDC resolved, attempting to get TGT... (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] [create_tgt_req_send_buffer] (0x1000): buffer size: 56 (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] [child_handler_setup] (0x2000): Setting up signal handler up for pid [3734] (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] [child_handler_setup] (0x2000): Signal handler set up for pid [3734] (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] [set_tgt_child_timeout] (0x0400): Setting 6 seconds timeout for tgt child (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] [sdap_process_result] (0x2000): Trace: sh[0xa45960], connected[1], ops[(nil)], ldap[0xa12200] (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] [write_pipe_handler] (0x0400): All data has been sent! (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] [child_sig_handler] (0x1000): Waiting for child [3734]. (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] [child_sig_handler] (0x0100): child [3734] finished successfully. (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] [sss_child_handler] (0x2000): waitpid failed [10]: No child processes (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] [read_pipe_handler] (0x0400): EOF received, client finished (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_tgt_recv] (0x0400): Child responded: 0 [FILE:/var/lib/sss/db/ccache_SERVER-IPA], expired on [1385420045] (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] [sdap_cli_auth_step] (0x0100): expire timeout is 900 (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] [sdap_cli_auth_step] (0x1000): the connection will expire at 1385334545 (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] [sasl_bind_send] (0x0100): Executing sasl bind mech: GSSAPI, user: host/tardis.ipa.server-noc.com (Mon Nov 25 08:54:11 2013) [sssd[be[ipa.server-noc.com]]] [sasl_bind_send] (0x0020): ldap_sasl_bind failed (-5)[Timed out] (Mon Nov 25 08:54:11 2013) [sssd[be[ipa.server-noc.com]]] [sasl_bind_send] (0x0080): Extended failure message: [unknown error] (Mon Nov 25 08:54:11 2013) [sssd[be[ipa.server-noc.com]]] [fo_set_port_status] (0x0100): Marking port 0 of server 'tardis.ipa.server-noc.com' as 'not working' (Mon Nov 25 08:54:11 2013) [sssd[be[ipa.server-noc.com]]] [sdap_handle_release] (0x2000): Trace: sh[0xa45960], connected[1], ops[(nil)], ldap[0xa12200], destructor_lock[0], release_memory[0] .. .. it then goes on to connect to fail over server and succeed and shortly after the master server is tested and marked as working again ... works for a couple of times then time out again .. any pointers gratefully received. packages used ... ipa-server-3.0.0-25.el6.x86_64 sssd-1.9.2-82.11.el6_4.x86_64 rgds Matt Bryant From sbose at redhat.com Mon Nov 25 08:49:15 2013 From: sbose at redhat.com (Sumit Bose) Date: Mon, 25 Nov 2013 09:49:15 +0100 Subject: [Freeipa-users] Intermittent Issues changing passwords since updating to ipa v3 and sasl_bind timeouts .. In-Reply-To: <52928A6A.9000802@melbourneit.com.au> References: <52928A6A.9000802@melbourneit.com.au> Message-ID: <20131125084915.GG3414@localhost.localdomain> On Mon, Nov 25, 2013 at 09:23:22AM +1000, Matt Bryant wrote: > All, > > Was wondering if anyone can help out or point us the in right > direction. Ever since we updated from IPA v2.1 to IPA v3.0 have been > seeing some intermittent errors when trying to change passwords etc. > Getting the error cannot change password since system offline. > > Have increased the logging and found that quite frequently the > sasl_bind using the host principle is timing out and failing ... > (whether this is red herring or not dont know but cant be good > anyhow) > > (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] > [sdap_kinit_send] (0x0400): Attempting kinit (default, > host/tardis.ipa.server-noc.com, SERVER-IPA, 86400) > (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] > [sdap_kinit_next_kdc] (0x1000): Resolving next KDC for service IPA > (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] > [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' > (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] > [get_server_status] (0x1000): Status of server > 'tardis.ipa.server-noc.com' is 'working' > (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] > [fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set > to 10 seconds > (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] > [get_server_status] (0x1000): Status of server > 'tardis.ipa.server-noc.com' is 'working' > (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] > [be_resolve_server_process] (0x1000): Saving the first resolved > server > (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] > [be_resolve_server_process] (0x0200): Found address for server > tardis.ipa.server-noc.com: [203.147.190.30] TTL 7200 > (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] > [sdap_kinit_kdc_resolved] (0x1000): KDC resolved, attempting to get > TGT... > (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] > [create_tgt_req_send_buffer] (0x1000): buffer size: 56 > (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] > [child_handler_setup] (0x2000): Setting up signal handler up for pid > [3734] > (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] > [child_handler_setup] (0x2000): Signal handler set up for pid [3734] > (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] > [set_tgt_child_timeout] (0x0400): Setting 6 seconds timeout for tgt > child > (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] > [sdap_process_result] (0x2000): Trace: sh[0xa45960], connected[1], > ops[(nil)], ldap[0xa12200] > (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] > [sdap_process_result] (0x2000): Trace: ldap_result found nothing! > (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] > [write_pipe_handler] (0x0400): All data has been sent! > (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] > [child_sig_handler] (0x1000): Waiting for child [3734]. > (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] > [child_sig_handler] (0x0100): child [3734] finished successfully. > (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] > [sss_child_handler] (0x2000): waitpid failed [10]: No child > processes > (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] > [read_pipe_handler] (0x0400): EOF received, client finished > (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] > [sdap_get_tgt_recv] (0x0400): Child responded: 0 > [FILE:/var/lib/sss/db/ccache_SERVER-IPA], expired on [1385420045] > (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] > [sdap_cli_auth_step] (0x0100): expire timeout is 900 > (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] > [sdap_cli_auth_step] (0x1000): the connection will expire at > 1385334545 > (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] > [sasl_bind_send] (0x0100): Executing sasl bind mech: GSSAPI, user: > host/tardis.ipa.server-noc.com > (Mon Nov 25 08:54:11 2013) [sssd[be[ipa.server-noc.com]]] > [sasl_bind_send] (0x0020): ldap_sasl_bind failed (-5)[Timed out] > (Mon Nov 25 08:54:11 2013) [sssd[be[ipa.server-noc.com]]] > [sasl_bind_send] (0x0080): Extended failure message: [unknown error] > (Mon Nov 25 08:54:11 2013) [sssd[be[ipa.server-noc.com]]] > [fo_set_port_status] (0x0100): Marking port 0 of server > 'tardis.ipa.server-noc.com' as 'not working' > (Mon Nov 25 08:54:11 2013) [sssd[be[ipa.server-noc.com]]] > [sdap_handle_release] (0x2000): Trace: sh[0xa45960], connected[1], > ops[(nil)], ldap[0xa12200], destructor_lock[0], release_memory[0] > .. > .. > > it then goes on to connect to fail over server and succeed and > shortly after the master server is tested and marked as working > again ... works for a couple of times then time out again .. any > pointers gratefully received. According to the logs I would say that this timeout happens on the LDAP server side. Do you have a chance to check the server logs to see what happens at this time on the server? You can increase the timeout value on the client by setting ldap_opt_timeout to a larger value then 6 (the default). But please note that the operation might take longer then letting SSSD fail over to the next server. HTH bye, Sumit > > > packages used ... > > ipa-server-3.0.0-25.el6.x86_64 > sssd-1.9.2-82.11.el6_4.x86_64 > > rgds > > Matt Bryant > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From emil at melt.se Mon Nov 25 15:14:22 2013 From: emil at melt.se (Emil Petersson) Date: Mon, 25 Nov 2013 16:14:22 +0100 Subject: [Freeipa-users] IPA winsync replication Message-ID: <5293694E.9060606@melt.se> Hi, I'm running FreeIPA 3.0 under RHEL6.4. I'm seeing some unexpected behaviour with winsync replication. 1. I have a working winsync agreement, and users are synced correctly. 2. If a user already exists in in IPA when I sync it from AD, I'm seeing the following in the dirsrv error logs: [25/Nov/2013:14:29:03 +0000] NSMMReplicationPlugin - windows_update_local_entry: failed to modify entry uid=username,cn=users,cn=accounts,dc=domain,dc=net - error 21:Invalid syntax I assume this is because the user already exists in dirsrv? Fine. 3. Then I remove the corresponding user from IPA and force another sync from AD, hoping that the user will sync properly this time, and thus have its ntUser* attributes created: [25/Nov/2013:14:29:09 +0000] NSMMReplicationPlugin - agmt="cn=meToAD.domain.com" (dc03:389): map_entry_dn_inbound: looking for local entry by uid [username] [25/Nov/2013:14:29:09 +0000] - Windows sync entry: Adding new local entry dn: uid=username,cn=users,cn=accounts,dc=domain,dc=net [25/Nov/2013:14:29:09 +0000] NSMMReplicationPlugin - add operation of entry uid=username,cn=users,cn=accounts,dc=domain,dc=net returned: 21 It's like something (either AD or IPA) remembers that a user have failed once, and then refuse to sync it any more. Removing the winsync agreement and recreating it completely doesn't help. The user is still not synced, and leaves error code 21. Anyone have any idea on why this is, and how I can sync the user even though it has failed once? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Mon Nov 25 16:21:03 2013 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 25 Nov 2013 09:21:03 -0700 Subject: [Freeipa-users] IPA winsync replication In-Reply-To: <5293694E.9060606@melt.se> References: <5293694E.9060606@melt.se> Message-ID: <529378EF.3040907@redhat.com> On 11/25/2013 08:14 AM, Emil Petersson wrote: > Hi, > > I'm running FreeIPA 3.0 under RHEL6.4. I'm seeing some unexpected > behaviour with winsync replication. > > 1. I have a working winsync agreement, and users are synced correctly. > > 2. If a user already exists in in IPA when I sync it from AD, I'm > seeing the following in the dirsrv error logs: > > [25/Nov/2013:14:29:03 +0000] NSMMReplicationPlugin - > windows_update_local_entry: failed to modify entry > uid=username,cn=users,cn=accounts,dc=domain,dc=net - error 21:Invalid > syntax > > I assume this is because the user already exists in dirsrv? Fine. No. Error 21 is Invalid Syntax. This means the format of the data in the attribute in AD is not correct for the given syntax. For example, if the syntax is Integer, this means the data should be a valid integer. However, AD allows data that violates LDAP syntax. Can you post the data from the AD entry that corresponds to uid=username,cn=users,cn=accounts,dc=domain,dc=net? Please be sure to obscure any sensitive data. I'd like to identify the data that is causing this problem. > > 3. Then I remove the corresponding user from IPA and force another > sync from AD, hoping that the user will sync properly this time, and > thus have its ntUser* attributes created: > > [25/Nov/2013:14:29:09 +0000] NSMMReplicationPlugin - > agmt="cn=meToAD.domain.com" (dc03:389): map_entry_dn_inbound: looking > for local entry by uid [username] > [25/Nov/2013:14:29:09 +0000] - Windows sync entry: Adding new > local entry dn: uid=username,cn=users,cn=accounts,dc=domain,dc=net > [25/Nov/2013:14:29:09 +0000] NSMMReplicationPlugin - add operation > of entry uid=username,cn=users,cn=accounts,dc=domain,dc=net returned: 21 > > It's like something (either AD or IPA) remembers that a user have > failed once, and then refuse to sync it any more. Removing the winsync > agreement and recreating it completely doesn't help. The user is still > not synced, and leaves error code 21. > > Anyone have any idea on why this is, and how I can sync the user even > though it has failed once? > > > > > _______________________________________________ > 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 sailer at sailer.dynip.lugs.ch Mon Nov 25 17:42:01 2013 From: sailer at sailer.dynip.lugs.ch (Thomas Sailer) Date: Mon, 25 Nov 2013 18:42:01 +0100 Subject: [Freeipa-users] Certificates not renewed Message-ID: <52938BE9.9070508@sailer.dynip.lugs.ch> I have a few certificates that fail to be updated, for example the ldap and http certificates. If I read the error message from getcert list (see below) correctly, then the contents of the pinfiles are incorrect. How do I fix this? Thanks, Tom Number of certificates and requests being tracked: 8. Request ID '20111116140151': status: CA_UNREACHABLE ca-error: Server failed request, will retry: 4301 (RPC failed at server. Certificate operation cannot be completed: EXCEPTION (Invalid Credential.)). stuck: yes key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-XXXX-COM',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-XXXX-COM//pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd-XXXX-COM',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=XXXX.COM subject: CN=server.xxxx.com,O=XXXX.COM expires: 2013-11-16 14:01:50 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes Request ID '20111116140217': status: CA_UNREACHABLE ca-error: Server failed request, will retry: 4301 (RPC failed at server. Certificate operation cannot be completed: EXCEPTION (Invalid Credential.)). stuck: yes key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA//pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=XXXX.COM subject: CN=server.xxxx.com,O=XXXX.COM expires: 2013-11-16 14:02:17 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes Request ID '20111116140238': status: CA_UNREACHABLE ca-error: Server failed request, will retry: 4301 (RPC failed at server. Certificate operation cannot be completed: EXCEPTION (Invalid Credential.)). stuck: yes key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=XXXX.COM subject: CN=server.xxxx.com,O=XXXX.COM expires: 2013-11-16 14:02:38 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes Request ID '20130424090625': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='auditSigningCert cert-pki-ca',token='NSS Certificate DB',pin='399557979284' certificate: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='auditSigningCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-renew-agent issuer: CN=Certificate Authority,O=XXXX.COM subject: CN=CA Audit,O=XXXX.COM expires: 2015-09-29 09:22:17 UTC key usage: digitalSignature,nonRepudiation pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert "auditSigningCert cert-pki-ca" track: yes auto-renew: yes Request ID '20130424090626': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='ocspSigningCert cert-pki-ca',token='NSS Certificate DB',pin='399557979284' certificate: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='ocspSigningCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-renew-agent issuer: CN=Certificate Authority,O=XXXX.COM subject: CN=OCSP Subsystem,O=XXXX.COM expires: 2015-09-29 09:21:17 UTC eku: id-kp-OCSPSigning pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert "ocspSigningCert cert-pki-ca" track: yes auto-renew: yes Request ID '20130424090627': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB',pin='399557979284' certificate: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-renew-agent issuer: CN=Certificate Authority,O=XXXX.COM subject: CN=CA Subsystem,O=XXXX.COM expires: 2015-09-29 09:21:17 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert "subsystemCert cert-pki-ca" track: yes auto-renew: yes Request ID '20130424090628': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' certificate: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB' CA: dogtag-ipa-renew-agent issuer: CN=Certificate Authority,O=XXXX.COM subject: CN=IPA RA,O=XXXX.COM expires: 2015-09-29 09:21:17 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: /usr/lib64/ipa/certmonger/renew_ra_cert track: yes auto-renew: yes Request ID '20130424090629': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert cert-pki-ca',token='NSS Certificate DB',pin='399557979284' certificate: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-renew-agent issuer: CN=Certificate Authority,O=XXXX.COM subject: CN=server.xxxx.com,O=XXXX.COM expires: 2015-09-29 09:21:17 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes From rcritten at redhat.com Mon Nov 25 18:09:45 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 25 Nov 2013 13:09:45 -0500 Subject: [Freeipa-users] CA expiration and renewal In-Reply-To: <52842407.80504@gmail.com> References: <52842407.80504@gmail.com> Message-ID: <52939269.1070405@redhat.com> Erinn Looney-Triggs wrote: > Folks just wanted to touch base again before the American holiday season > starts. My CA, which is subordinate to AD CS will be expiring on > December 9th, I submitted a bug, y'all drew up docs etc for a plan > (thanks). Now I just wanted to see how it was going and if need be what > manual steps I will need to take to renew the certificate. > > Thanks again for the great work, We're working on an a set of tools to make this easier. For now I've appended some manual instructions onto a page still in progress. http://www.freeipa.org/page/Howto/CA_Certificate_Renewal#Manual_Procedure_in_IPA_3.0 Some parts may be still be a little rough or hard to understand. Let me know if you have any problems or corrections. rob From rcritten at redhat.com Mon Nov 25 18:21:51 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 25 Nov 2013 13:21:51 -0500 Subject: [Freeipa-users] Certificates not renewed In-Reply-To: <52938BE9.9070508@sailer.dynip.lugs.ch> References: <52938BE9.9070508@sailer.dynip.lugs.ch> Message-ID: <5293953F.7030200@redhat.com> Thomas Sailer wrote: > I have a few certificates that fail to be updated, for example the ldap > and http certificates. If I read the error message from getcert list > (see below) correctly, then the contents of the pinfiles are incorrect. > How do I fix this? > > Thanks, > Tom > Does this work? # ipa cert-show 1 I'm geussing it doesn't. The nickname ipaCert in /etc/httpd/alias is the RA agent cert used to authenticate to dogtag when doing certificate operations. I suspect that its value hasn't been updated in the dogtag LDAP database. A quick way to tell is: # certutil -L -d /etc/httpd/alias -n ipaCert | grep -i serial # ldapsearch -x -h localhost -p 7389 -D 'cn=directory manager' -W -b uid=ipara,ou=People,o=ipaca description This is assuming you've got a 2-instance installation where there is a separate 389-ds instance for IPA and the CA. If you have a newer install then the port isn't necessary. If the serial number from certutil doesn't match the second colon-separated value then that explains it. You can see how to update this value at http://www.freeipa.org/page/IPA_2x_Certificate_Renewal rob From t.sailer at alumni.ethz.ch Mon Nov 25 18:35:04 2013 From: t.sailer at alumni.ethz.ch (Thomas Sailer) Date: Mon, 25 Nov 2013 19:35:04 +0100 Subject: [Freeipa-users] Certificates not renewed In-Reply-To: <5293953F.7030200@redhat.com> References: <52938BE9.9070508@sailer.dynip.lugs.ch> <5293953F.7030200@redhat.com> Message-ID: <52939858.20908@alumni.ethz.ch> Hi Rob, thanks for the quick answer! > Does this work? > > # ipa cert-show 1 > > I'm geussing it doesn't. You're correct, it doesn't. You are correct, the serial numbers didn't match. I've fixed this, now I get the following error: Request ID '20111116140151': status: CA_UNREACHABLE ca-error: Server failed request, will retry: 4301 (RPC failed at server. Certificate operation cannot be completed: FAILURE (Profile caIPAserviceCert Not Found)). Thanks, Tom From emil at melt.se Mon Nov 25 18:51:22 2013 From: emil at melt.se (Emil Petersson) Date: Mon, 25 Nov 2013 19:51:22 +0100 Subject: [Freeipa-users] IPA winsync replication In-Reply-To: <529378EF.3040907@redhat.com> References: <5293694E.9060606@melt.se> <529378EF.3040907@redhat.com> Message-ID: On 25 Nov 2013, at 17:21, Rich Megginson wrote: > On 11/25/2013 08:14 AM, Emil Petersson wrote: >> Hi, >> >> I'm running FreeIPA 3.0 under RHEL6.4. I'm seeing some unexpected behaviour with winsync replication. >> >> 1. I have a working winsync agreement, and users are synced correctly. >> >> 2. If a user already exists in in IPA when I sync it from AD, I'm seeing the following in the dirsrv error logs: >> >> [25/Nov/2013:14:29:03 +0000] NSMMReplicationPlugin - windows_update_local_entry: failed to modify entry uid=username,cn=users,cn=accounts,dc=domain,dc=net - error 21:Invalid syntax >> >> I assume this is because the user already exists in dirsrv? Fine. > > No. Error 21 is Invalid Syntax. This means the format of the data in the attribute in AD is not correct for the given syntax. For example, if the syntax is Integer, this means the data should be a valid integer. However, AD allows data that violates LDAP syntax. > > Can you post the data from the AD entry that corresponds to uid=username,cn=users,cn=accounts,dc=domain,dc=net? Please be sure to obscure any sensitive data. I'd like to identify the data that is causing this problem. Certainly, here goes: dn: CN=Firstname Lastname,OU=LDAP,OU=Domain,OU=Users,OU=Domain,OU=Organization,DC= domain,DC=com objectClass: top objectClass: person objectClass: organizationalPerson objectClass: user cn: Firstname Lastname sn: Lastname title: Sysadmin description: Employee physicalDeliveryOfficeName: XX-XX-XX telephoneNumber: +00 00 000 0 facsimileTelephoneNumber: +00 00 000 0 givenName: Firstname distinguishedName: CN=Firstname Lastname,OU=LDAP,OU=Domain,OU=Users,OU=Domain,OU=O rganization,DC=domain,DC=com instanceType: 4 whenCreated: 20110321122858.0Z whenChanged: 20131120104224.0Z displayName: Firstname Lastname uSNCreated: 76590 ngame,DC=com memberOf: CN=All,OU=OrgGroups,OU=Organization,DC=domain,DC=com memberOf: CN=sysadmins,OU=OrgGroups,OU=Organization,DC=domain,DC=com uSNChanged: 66378160 department: Infrastructure company: Company name homeMTA: CN=Microsoft MTA,CN=MBX,CN=Servers,CN=Exchange Administrative Group ( FYDIBOHF23SPDLT),CN=Administrative Groups,CN=globalmail,CN=Microsoft Exchange ,CN=Services,CN=Configuration,DC=domain,DC=com proxyAddresses: SMTP:first.last at domain.com proxyAddresses: smtp:first.last at domain2.com proxyAddresses: smtp:first.last at domain3.com proxyAddresses: sip:first.last at domain.com proxyAddresses: X400:C=SE;A= ;P=globalmail;O=Exchange;S=Lastname;G=Firstname; homeMDB: CN=DB3,CN=SG03 - 2GB,CN=InformationStore,CN=MBX,CN=Servers,CN=Exchang e Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=globalma il,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain,DC=com garbageCollPeriod: 1209600 mDBUseDefaults: TRUE extensionAttribute8: Companyname mailNickname: username protocolSettings:: SFRUUMKnMcKnMcKnwqfCp8KnwqfCpw== protocolSettings:: T1dBwqcx internetEncoding: 0 name: Firstnam Lastname objectGUID:: pDdL7yY7gEuqRdQLTjLo0w== userAccountControl: 512 badPwdCount: 0 codePage: 0 countryCode: 0 homeDirectory: \\path\to\home homeDrive: H: badPasswordTime: 130295283826410995 lastLogoff: 0 lastLogon: 130297464093469882 pwdLastSet: 130294130189116476 primaryGroupID: 513 objectSid:: AQUAAAoiadjfojdfojsodijfQkAH5TsrAA== accountExpires: 0 logonCount: 6909 sAMAccountName: username sAMAccountType: 805306368 showInAddressBook: CN=Default Global Address List,CN=All Global Address Lists, CN=Address Lists Container,CN=globalmail,CN=Microsoft Exchange,CN=Services,CN =Configuration,DC=domain,DC=com showInAddressBook: CN=All Users,CN=All Address Lists,CN=Address Lists Containe r,CN=globalmail,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain, DC=com legacyExchangeDN: /o=globalmail/ou=Exchange Administrative Group (FYDIBOHF23SP DLT)/cn=Recipients/cn=username userPrincipalName: first at domain.com lockoutTime: 0 ipPhone: +00 00 00 00 objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=domain,DC=com dSCorePropagationData: 20131118102944.0Z dSCorePropagationData: 20131118102934.0Z dSCorePropagationData: 20130313150036.0Z dSCorePropagationData: 20120821144903.0Z dSCorePropagationData: 16010101181216.0Z lastLogonTimestamp: 130294177442871790 textEncodedORAddress: c=XX;a= ;p=globalmail;o=Exchange;s=Lastname;g=Firstname; mail: first.last at domain.com manager: CN=Manager Name,OU=Domain,OU=Users,OU=Domain,OU=Organization,DC=o ngame,DC=com mobile:: KzQ2NzI3mjMEMTEwwqAJ thumbnailPhoto:: /9j/4QAYRXhpZgAASUkqAAgAAAAAAAAAAAAAAP/sABFEdWNreQABAAQAAABkA -snip- uaC3IbWlp5cQtpnwnCmjkd9LrDoNFIUDThZwzyrwJbl21//9k= msExchHomeServerName: /o=globalmail/ou=Exchange Administrative Group (FYDIBOHF 23SPDLT)/cn=Configuration/cn=Servers/cn=MBX msExchMailboxSecurityDescriptor:: AQAUjBQAAAAgAAAALAAAAFwAAAABAQAAAAAABQoAAAAB -snip- AQAAAAAABQoAAAACADAAAgAAAALQFAADAA0AAQEAAAAAAAEAAAAAAtoUAGsBDQABAQAAAAAAAQAAA msExchUserAccountControl: 0 msExchMailboxGuid:: uWv8V7HNHUiyda0z/FRc+w== msExchPoliciesIncluded: {A64061C3-9598-43A1-9125-B5C682DEDA40},{26491CFC-9E50- 4857-861B-0CB8DF22B5D7} msRTCSIP-Line: TEL:+46812136492 msRTCSIP-DeploymentLocator: SRV: msExchUserCulture: sv-SE,en-US msExchMobileMailboxFlags: 1 msExchRecipientDisplayType: 1073741824 msExchVersion: 4535486012416 msRTCSIP-FederationEnabled: TRUE msRTCSIP-PrimaryUserAddress: sip:first.last at domain.com msExchRecipientTypeDetails: 1 msRTCSIP-InternetAccessEnabled: TRUE msRTCSIP-UserPolicies: 0=481565286 msExchMDBRulesQuota: 64 msRTCSIP-OptionFlags: 385 msRTCSIP-UserEnabled: TRUE msRTCSIP-PrimaryHomeServer: CN=Lc Services,CN=Microsoft,CN=1:1,CN=Pools,CN=RTC Service,CN=Services,CN=Configuration,DC=domain,DC=com Please note that the same user would sync OK if I hadn't attempted to sync it earlier when the duplicate IPA entry was in place. This is the strangest part... once a user is synced and there's a duplicate in place, we get error 21 and after that the user will be ignored in future syncs. Even if we recreate the agreement. Question, if a duplicate entry exists in IPA, what's the expected behaviour? Should the user get synced anyway, or should it fail? Please let me know if you need anything else. Setting nsslapd-errorlog-level: 8192 more or less says the same thing... error 21, and then it just moves on. I could provide you with the debug though, if wanted. > >> >> 3. Then I remove the corresponding user from IPA and force another sync from AD, hoping that the user will sync properly this time, and thus have its ntUser* attributes created: >> >> [25/Nov/2013:14:29:09 +0000] NSMMReplicationPlugin - agmt="cn=meToAD.domain.com" (dc03:389): map_entry_dn_inbound: looking for local entry by uid [username] >> [25/Nov/2013:14:29:09 +0000] - Windows sync entry: Adding new local entry dn: uid=username,cn=users,cn=accounts,dc=domain,dc=net >> [25/Nov/2013:14:29:09 +0000] NSMMReplicationPlugin - add operation of entry uid=username,cn=users,cn=accounts,dc=domain,dc=net returned: 21 >> >> It's like something (either AD or IPA) remembers that a user have failed once, and then refuse to sync it any more. Removing the winsync agreement and recreating it completely doesn't help. The user is still not synced, and leaves error code 21. >> >> Anyone have any idea on why this is, and how I can sync the user even though it has failed once? -------------- next part -------------- An HTML attachment was scrubbed... URL: From t.sailer at alumni.ethz.ch Mon Nov 25 19:07:43 2013 From: t.sailer at alumni.ethz.ch (Thomas Sailer) Date: Mon, 25 Nov 2013 20:07:43 +0100 Subject: [Freeipa-users] Certificates not renewed In-Reply-To: <52939858.20908@alumni.ethz.ch> References: <52938BE9.9070508@sailer.dynip.lugs.ch> <5293953F.7030200@redhat.com> <52939858.20908@alumni.ethz.ch> Message-ID: <52939FFF.8050703@alumni.ethz.ch> I seem to be a victim of BZ 675742 > I've fixed this, now I get the following error: > Request ID '20111116140151': > status: CA_UNREACHABLE > ca-error: Server failed request, will retry: 4301 (RPC failed > at server. Certificate operation cannot be completed: FAILURE > (Profile caIPAserviceCert Not Found)). chown pkiuser.pkiuser /var/lib/pki-ca/profiles/ca/caIPAserviceCert.cfg and systemctl restart pki-cad at pki-ca.service has fixed it, all tracked certs are now in MONITORING state Thanks Tom From rcritten at redhat.com Mon Nov 25 19:17:59 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 25 Nov 2013 14:17:59 -0500 Subject: [Freeipa-users] Certificates not renewed [SOLVED] In-Reply-To: <52939FFF.8050703@alumni.ethz.ch> References: <52938BE9.9070508@sailer.dynip.lugs.ch> <5293953F.7030200@redhat.com> <52939858.20908@alumni.ethz.ch> <52939FFF.8050703@alumni.ethz.ch> Message-ID: <5293A267.40209@redhat.com> Thomas Sailer wrote: > I seem to be a victim of BZ 675742 > >> I've fixed this, now I get the following error: >> Request ID '20111116140151': >> status: CA_UNREACHABLE >> ca-error: Server failed request, will retry: 4301 (RPC failed >> at server. Certificate operation cannot be completed: FAILURE >> (Profile caIPAserviceCert Not Found)). > > chown pkiuser.pkiuser /var/lib/pki-ca/profiles/ca/caIPAserviceCert.cfg > > and > > systemctl restart pki-cad at pki-ca.service > > has fixed it, all tracked certs are now in MONITORING state Great, thanks for the follow-up. rob From t.sailer at alumni.ethz.ch Mon Nov 25 19:53:59 2013 From: t.sailer at alumni.ethz.ch (Thomas Sailer) Date: Mon, 25 Nov 2013 20:53:59 +0100 Subject: [Freeipa-users] Certificates not renewed [SOLVED] In-Reply-To: <5293A267.40209@redhat.com> References: <52938BE9.9070508@sailer.dynip.lugs.ch> <5293953F.7030200@redhat.com> <52939858.20908@alumni.ethz.ch> <52939FFF.8050703@alumni.ethz.ch> <5293A267.40209@redhat.com> Message-ID: <5293AAD7.6060804@alumni.ethz.ch> > Great, thanks for the follow-up. I was a bit too soon. After sending the mail, I saw that the freeipa web GUI no longer worked. It turned out that I ended up with two certificates with the name Server-Cert in both the httpd and slapd certificate databases. It doesn't seem to be possible using certutil to selectively delete one of the two certificates, so I exported both, deleted both, and used an ASCII editor to extract the correct one and reimport it. After restarting httpd, the web gui now works again. Tom From matthew.bryant at melbourneit.com.au Mon Nov 25 23:47:10 2013 From: matthew.bryant at melbourneit.com.au (Matt Bryant) Date: Tue, 26 Nov 2013 09:47:10 +1000 Subject: [Freeipa-users] Intermittent Issues changing passwords since updating to ipa v3 and sasl_bind timeouts .. In-Reply-To: <20131125084915.GG3414@localhost.localdomain> References: <52928A6A.9000802@melbourneit.com.au> <20131125084915.GG3414@localhost.localdomain> Message-ID: <5293E17E.7040801@melbourneit.com.au> After some further digging I tend to agree that its in the LDAP arena where the issue lies .. but there is nothing in the ldap_child log thats helping out .. (btw the other replica IPA servers dont seem to encounter this issue just the master (ie the server with CA responsibility) ... Also more logs (sigh) dont understand though how a server can be marked as working and in the same second fail ... or what call is causing an input/output error ... :( (Tue Nov 26 09:14:58 2013) [sssd[be[ipa.server-noc.com]]] [sasl_bind_send] (0x0100): Executing sasl bind mech: GSSAPI, user: host/tardis.ipa.server-noc.com (Tue Nov 26 09:15:04 2013) [sssd[be[ipa.server-noc.com]]] [sasl_bind_send] (0x0020): ldap_sasl_bind failed (-5)[Timed out] (Tue Nov 26 09:15:04 2013) [sssd[be[ipa.server-noc.com]]] [sasl_bind_send] (0x0080): Extended failure message: [unknown error] (Tue Nov 26 09:15:04 2013) [sssd[be[ipa.server-noc.com]]] [fo_set_port_status] (0x0100): Marking port 0 of server 'tardis.ipa.server-noc.com' as 'not working' (Tue Nov 26 09:15:04 2013) [sssd[be[ipa.server-noc.com]]] [sdap_handle_release] (0x2000): Trace: sh[0x17dcf50], connected[1], ops[(nil)], ldap[0x17d6920], destructor_lock[0], release_memory[0] (Tue Nov 26 09:15:04 2013) [sssd[be[ipa.server-noc.com]]] [remove_connection_callback] (0x4000): Successfully removed connection callback. (Tue Nov 26 09:15:04 2013) [sssd[be[ipa.server-noc.com]]] [sdap_id_op_connect_done] (0x4000): notify error to op #1: 5 [Input/output error] (Tue Nov 26 09:15:04 2013) [sssd[be[ipa.server-noc.com]]] [acctinfo_callback] (0x0100): Request processed. Returned 3,5,User lookup failed (Tue Nov 26 09:15:04 2013) [sssd[be[ipa.server-noc.com]]] [sdap_id_release_conn_data] (0x4000): releasing unused connection (Tue Nov 26 09:15:04 2013) [sssd[be[ipa.server-noc.com]]] [sbus_dispatch] (0x4000): dbus conn: 174A470 (Tue Nov 26 09:15:04 2013) [sssd[be[ipa.server-noc.com]]] [sbus_dispatch] (0x4000): Dispatching. (Tue Nov 26 09:15:04 2013) [sssd[be[ipa.server-noc.com]]] [sbus_message_handler] (0x4000): Received SBUS method [getAccountInfo] (Tue Nov 26 09:15:04 2013) [sssd[be[ipa.server-noc.com]]] [be_get_account_info] (0x0100): Got request for [4097][1][name=nobody] (Tue Nov 26 09:15:04 2013) [sssd[be[ipa.server-noc.com]]] [sdap_id_op_connect_step] (0x4000): beginning to connect (Tue Nov 26 09:15:04 2013) [sssd[be[ipa.server-noc.com]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' (Tue Nov 26 09:15:04 2013) [sssd[be[ipa.server-noc.com]]] [get_server_status] (0x1000): Status of server 'tardis.ipa.server-noc.com' is 'working' (Tue Nov 26 09:15:04 2013) [sssd[be[ipa.server-noc.com]]] [get_port_status] (0x1000): Port status of port 0 for server 'tardis.ipa.server-noc.com' is 'not working' (Tue Nov 26 09:15:04 2013) [sssd[be[ipa.server-noc.com]]] [fo_resolve_service_send] (0x0020): No available servers for service 'IPA' (Tue Nov 26 09:15:04 2013) [sssd[be[ipa.server-noc.com]]] [be_resolve_server_done] (0x1000): Server resolution failed: 5 (Tue Nov 26 09:15:04 2013) [sssd[be[ipa.server-noc.com]]] [sdap_id_op_connect_done] (0x0020): Failed to connect, going offline (5 [Input/output error]) (Tue Nov 26 09:15:04 2013) [sssd[be[ipa.server-noc.com]]] [be_mark_offline] (0x2000): Going offline! (Tue Nov 26 09:15:04 2013) [sssd[be[ipa.server-noc.com]]] [be_run_offline_cb] (0x0080): Going offline. Running callbacks. (Tue Nov 26 09:15:04 2013) [sssd[be[ipa.server-noc.com]]] [sdap_id_op_connect_done] (0x4000): notify offline to op #1 (Tue Nov 26 09:15:04 2013) [sssd[be[ipa.server-noc.com]]] [acctinfo_callback] (0x0100): Request processed. Returned 1,11,Offline (Tue Nov 26 09:15:04 2013) [sssd[be[ipa.server-noc.com]]] [sdap_id_release_conn_data] (0x4000): releasing unused connection ... ... (Tue Nov 26 09:16:12 2013) [sssd[be[ipa.server-noc.com]]] [sbus_dispatch] (0x4000): dbus conn: 171FDB0 (Tue Nov 26 09:16:12 2013) [sssd[be[ipa.server-noc.com]]] [sbus_dispatch] (0x4000): Dispatching. (Tue Nov 26 09:16:12 2013) [sssd[be[ipa.server-noc.com]]] [sbus_message_handler] (0x4000): Received SBUS method [ping] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sbus_dispatch] (0x4000): dbus conn: 174A470 (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sbus_dispatch] (0x4000): Dispatching. (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sbus_message_handler] (0x4000): Received SBUS method [getAccountInfo] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [be_get_account_info] (0x0100): Got request for [4097][1][idnumber=493] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [be_get_account_info] (0x0100): Request processed. Returned 1,11,Fast reply - offline (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_id_op_connect_step] (0x4000): beginning to connect (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [get_server_status] (0x1000): Status of server 'tardis.ipa.server-noc.com' is 'working' (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [get_port_status] (0x1000): Port status of port 0 for server 'tardis.ipa.server-noc.com' is 'not working' (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [get_port_status] (0x0100): Reseting the status of port 0 for server 'tardis.ipa.server-noc.com' (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set to 10 seconds (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [get_server_status] (0x1000): Status of server 'tardis.ipa.server-noc.com' is 'working' (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [be_resolve_server_process] (0x1000): Saving the first resolved server (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [be_resolve_server_process] (0x0200): Found address for server tardis.ipa.server-noc.com: [203.147.190.30] TTL 7200 (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [ipa_resolve_callback] (0x0400): Constructed uri 'ldap://tardis.ipa.server-noc.com' (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sss_ldap_init_send] (0x4000): Using file descriptor [19] for LDAP connection. (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sss_ldap_init_send] (0x0400): Setting 10 seconds timeout for connecting (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_ldap_connect_callback_add] (0x1000): New LDAP connection to [ldap://tardis.ipa.server-noc.com:389/??base] with fd [19]. (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_rootdse_send] (0x4000): Getting rootdse (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(objectclass=*)][]. (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [*] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [altServer] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [namingContexts] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedControl] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedExtension] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedFeatures] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedLDAPVersion] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedSASLMechanisms] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [domainControllerFunctionality] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [defaultNamingContext] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [lastUSN] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [highestCommittedUSN] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 1 (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sbus_dispatch] (0x4000): dbus conn: 174A470 (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sbus_dispatch] (0x4000): Dispatching. (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sbus_message_handler] (0x4000): Received SBUS method [getAccountInfo] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [be_get_account_info] (0x0100): Got request for [4097][1][*] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_process_result] (0x2000): Trace: sh[0x171e770], connected[1], ops[0x17dded0], ldap[0x17378e0] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_parse_entry] (0x4000): OriginalDN: []. (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectClass] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [namingContexts] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [defaultnamingcontext] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [supportedExtension] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [supportedControl] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [supportedSASLMechanisms] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [supportedLDAPVersion] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [vendorName] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [vendorVersion] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [dataversion] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [netscapemdsuffix] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [lastusn] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_process_result] (0x2000): Trace: sh[0x171e770], connected[1], ops[0x17dded0], ldap[0x17378e0] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_rootdse_done] (0x2000): Got rootdse (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_rootdse_done] (0x2000): Skipping auto-detection of match rule (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_server_opts_from_rootdse] (0x4000): USN value: 7097911 (int: 7097911) (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_kinit_send] (0x0400): Attempting kinit (default, host/tardis.ipa.server-noc.com, SERVER-IPA, 86400) (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_kinit_next_kdc] (0x1000): Resolving next KDC for service IPA (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [get_server_status] (0x1000): Status of server 'tardis.ipa.server-noc.com' is 'working' (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set to 10 seconds (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [get_server_status] (0x1000): Status of server 'tardis.ipa.server-noc.com' is 'working' (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [be_resolve_server_process] (0x1000): Saving the first resolved server (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [be_resolve_server_process] (0x0200): Found address for server tardis.ipa.server-noc.com: [203.147.190.30] TTL 7200 (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_kinit_kdc_resolved] (0x1000): KDC resolved, attempting to get TGT... (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [create_tgt_req_send_buffer] (0x1000): buffer size: 56 (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [child_handler_setup] (0x2000): Setting up signal handler up for pid [26046] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [child_handler_setup] (0x2000): Signal handler set up for pid [26046] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [set_tgt_child_timeout] (0x0400): Setting 6 seconds timeout for tgt child (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_process_result] (0x2000): Trace: sh[0x171e770], connected[1], ops[(nil)], ldap[0x17378e0] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [write_pipe_handler] (0x0400): All data has been sent! (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sbus_dispatch] (0x4000): dbus conn: 174A470 (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sbus_dispatch] (0x4000): Dispatching. (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sbus_message_handler] (0x4000): Received SBUS method [getAccountInfo] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [be_get_account_info] (0x0100): Got request for [4098][1][*] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sbus_dispatch] (0x4000): dbus conn: 174A470 (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sbus_dispatch] (0x4000): Dispatching. (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sbus_message_handler] (0x4000): Received SBUS method [getAccountInfo] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [be_get_account_info] (0x0100): Got request for [4097][1][idnumber=493] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_id_op_connect_step] (0x4000): waiting for connection to complete (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sbus_dispatch] (0x4000): dbus conn: 171FDB0 (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sbus_dispatch] (0x4000): Dispatching. (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sbus_message_handler] (0x4000): Received SBUS method [ping] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [child_sig_handler] (0x1000): Waiting for child [26046]. (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [child_sig_handler] (0x0100): child [26046] finished successfully. (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sss_child_handler] (0x2000): waitpid failed [10]: No child processes (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [read_pipe_handler] (0x0400): EOF received, client finished (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_tgt_recv] (0x0400): Child responded: 0 [FILE:/var/lib/sss/db/ccache_SERVER-IPA], expired on [1385507781] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_cli_auth_step] (0x0100): expire timeout is 900 (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_cli_auth_step] (0x1000): the connection will expire at 1385422282 (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sasl_bind_send] (0x0100): Executing sasl bind mech: GSSAPI, user: host/tardis.ipa.server-noc.com (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [fo_set_port_status] (0x0100): Marking port 0 of server 'tardis.ipa.server-noc.com' as 'working' (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [set_server_common_status] (0x0100): Marking server 'tardis.ipa.server-noc.com' as 'working' (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_id_op_connect_done] (0x2000): Old USN: 7097881, New USN: 7097911 (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_id_op_connect_done] (0x4000): notify connected to op #1 (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_users_next_base] (0x0400): Searching for users with base [cn=accounts,dc=server-ipa] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(uidNumber=493)(objectclass=posixAccount))][cn=accounts,dc=server-ipa]. (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uid] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userPassword] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uidNumber] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gidNumber] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gecos] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [homeDirectory] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginShell] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [krbPrincipalName] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberOf] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [nsUniqueId] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [modifyTimestamp] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [entryUSN] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowLastChange] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowMin] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowMax] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowWarning] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowInactive] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowExpire] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowFlag] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [krbLastPwdChange] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [krbPasswordExpiration] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [pwdAttribute] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [authorizedService] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [accountExpires] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userAccountControl] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [nsAccountLock] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [host] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginDisabled] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginExpirationTime] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginAllowedTimeMap] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaSshPubKey] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 5 (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_id_op_connect_done] (0x4000): notify connected to op #2 (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_users_next_base] (0x0400): Searching for users with base [cn=accounts,dc=server-ipa] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(uidNumber=493)(objectclass=posixAccount))][cn=accounts,dc=server-ipa]. (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uid] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userPassword] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uidNumber] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gidNumber] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gecos] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [homeDirectory] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginShell] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [krbPrincipalName] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberOf] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [nsUniqueId] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [modifyTimestamp] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [entryUSN] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowLastChange] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowMin] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowMax] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowWarning] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowInactive] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowExpire] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowFlag] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [krbLastPwdChange] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [krbPasswordExpiration] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [pwdAttribute] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [authorizedService] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [accountExpires] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userAccountControl] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [nsAccountLock] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [host] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginDisabled] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginExpirationTime] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginAllowedTimeMap] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaSshPubKey] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 6 (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_id_op_connect_done] (0x4000): caching successful connection after 2 notifies (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [be_run_online_cb] (0x0080): Going online. Running callbacks. (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sbus_dispatch] (0x4000): dbus conn: 174A470 (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sbus_dispatch] (0x4000): Dispatching. (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sbus_message_handler] (0x4000): Received SBUS method [getAccountInfo] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [be_get_account_info] (0x0100): Got request for [4097][1][idnumber=495] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_users_next_base] (0x0400): Searching for users with base [cn=accounts,dc=server-ipa] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(uidNumber=495)(objectclass=posixAccount))][cn=accounts,dc=server-ipa]. (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uid] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userPassword] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uidNumber] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gidNumber] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gecos] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [homeDirectory] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginShell] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [krbPrincipalName] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberOf] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [nsUniqueId] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [modifyTimestamp] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [entryUSN] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowLastChange] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowMin] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowMax] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowWarning] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowInactive] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowExpire] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowFlag] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [krbLastPwdChange] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [krbPasswordExpiration] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [pwdAttribute] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [authorizedService] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [accountExpires] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userAccountControl] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [nsAccountLock] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [host] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginDisabled] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginExpirationTime] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginAllowedTimeMap] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaSshPubKey] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 7 (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [objectclass=ipaNTTrustedDomain][cn=trusts,dc=server-ipa]. (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaNTFlatName] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaNTTrustedDomainSID] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 8 (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [delayed_online_authentication_callback] (0x0200): Backend is online, starting delayed online authentication. also seeing these errors ... Tue Nov 26 09:42:02 2013) [sssd[be[ipa.server-noc.com]]] [ldb] (0x4000): start ldb transaction (nesting: 0) (Tue Nov 26 09:42:02 2013) [sssd[be[ipa.server-noc.com]]] [sysdb_update_ranges] (0x0400): Adding range [SERVER-IPA_id_range]. (Tue Nov 26 09:42:02 2013) [sssd[be[ipa.server-noc.com]]] [sysdb_range_create] (0x0040): Invalid range, expected that either the secondary base rid or the SID of the trusted domain is set, but not both or none of them. (Tue Nov 26 09:42:02 2013) [sssd[be[ipa.server-noc.com]]] [sysdb_range_create] (0x0400): Error: 22 (Invalid argument) (Tue Nov 26 09:42:02 2013) [sssd[be[ipa.server-noc.com]]] [sysdb_update_ranges] (0x0040): sysdb_range_create failed. (Tue Nov 26 09:42:02 2013) [sssd[be[ipa.server-noc.com]]] [ldb] (0x4000): cancel ldb transaction (nesting: 0) (Tue Nov 26 09:42:02 2013) [sssd[be[ipa.server-noc.com]]] [ipa_subdomains_handler_ranges_done] (0x0040): sysdb_update_ranges failed. Have not setup any AD trusts etc ... rgds Matt B. On 11/25/2013 06:49 PM, Sumit Bose wrote: > On Mon, Nov 25, 2013 at 09:23:22AM +1000, Matt Bryant wrote: >> All, >> >> Was wondering if anyone can help out or point us the in right >> direction. Ever since we updated from IPA v2.1 to IPA v3.0 have been >> seeing some intermittent errors when trying to change passwords etc. >> Getting the error cannot change password since system offline. >> >> Have increased the logging and found that quite frequently the >> sasl_bind using the host principle is timing out and failing ... >> (whether this is red herring or not dont know but cant be good >> anyhow) >> >> (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] >> [sdap_kinit_send] (0x0400): Attempting kinit (default, >> host/tardis.ipa.server-noc.com, SERVER-IPA, 86400) >> (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] >> [sdap_kinit_next_kdc] (0x1000): Resolving next KDC for service IPA >> (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] >> [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' >> (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] >> [get_server_status] (0x1000): Status of server >> 'tardis.ipa.server-noc.com' is 'working' >> (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] >> [fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set >> to 10 seconds >> (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] >> [get_server_status] (0x1000): Status of server >> 'tardis.ipa.server-noc.com' is 'working' >> (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] >> [be_resolve_server_process] (0x1000): Saving the first resolved >> server >> (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] >> [be_resolve_server_process] (0x0200): Found address for server >> tardis.ipa.server-noc.com: [203.147.190.30] TTL 7200 >> (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] >> [sdap_kinit_kdc_resolved] (0x1000): KDC resolved, attempting to get >> TGT... >> (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] >> [create_tgt_req_send_buffer] (0x1000): buffer size: 56 >> (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] >> [child_handler_setup] (0x2000): Setting up signal handler up for pid >> [3734] >> (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] >> [child_handler_setup] (0x2000): Signal handler set up for pid [3734] >> (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] >> [set_tgt_child_timeout] (0x0400): Setting 6 seconds timeout for tgt >> child >> (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] >> [sdap_process_result] (0x2000): Trace: sh[0xa45960], connected[1], >> ops[(nil)], ldap[0xa12200] >> (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] >> [sdap_process_result] (0x2000): Trace: ldap_result found nothing! >> (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] >> [write_pipe_handler] (0x0400): All data has been sent! >> (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] >> [child_sig_handler] (0x1000): Waiting for child [3734]. >> (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] >> [child_sig_handler] (0x0100): child [3734] finished successfully. >> (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] >> [sss_child_handler] (0x2000): waitpid failed [10]: No child >> processes >> (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] >> [read_pipe_handler] (0x0400): EOF received, client finished >> (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] >> [sdap_get_tgt_recv] (0x0400): Child responded: 0 >> [FILE:/var/lib/sss/db/ccache_SERVER-IPA], expired on [1385420045] >> (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] >> [sdap_cli_auth_step] (0x0100): expire timeout is 900 >> (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] >> [sdap_cli_auth_step] (0x1000): the connection will expire at >> 1385334545 >> (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] >> [sasl_bind_send] (0x0100): Executing sasl bind mech: GSSAPI, user: >> host/tardis.ipa.server-noc.com >> (Mon Nov 25 08:54:11 2013) [sssd[be[ipa.server-noc.com]]] >> [sasl_bind_send] (0x0020): ldap_sasl_bind failed (-5)[Timed out] >> (Mon Nov 25 08:54:11 2013) [sssd[be[ipa.server-noc.com]]] >> [sasl_bind_send] (0x0080): Extended failure message: [unknown error] >> (Mon Nov 25 08:54:11 2013) [sssd[be[ipa.server-noc.com]]] >> [fo_set_port_status] (0x0100): Marking port 0 of server >> 'tardis.ipa.server-noc.com' as 'not working' >> (Mon Nov 25 08:54:11 2013) [sssd[be[ipa.server-noc.com]]] >> [sdap_handle_release] (0x2000): Trace: sh[0xa45960], connected[1], >> ops[(nil)], ldap[0xa12200], destructor_lock[0], release_memory[0] >> .. >> .. >> >> it then goes on to connect to fail over server and succeed and >> shortly after the master server is tested and marked as working >> again ... works for a couple of times then time out again .. any >> pointers gratefully received. > According to the logs I would say that this timeout happens on the > LDAP server side. Do you have a chance to check the server logs to see > what happens at this time on the server? > > You can increase the timeout value on the client by setting > ldap_opt_timeout to a larger value then 6 (the default). But please note > that the operation might take longer then letting SSSD fail over to the > next server. > > HTH > > bye, > Sumit > >> >> packages used ... >> >> ipa-server-3.0.0-25.el6.x86_64 >> sssd-1.9.2-82.11.el6_4.x86_64 >> >> rgds >> >> Matt Bryant >> >> _______________________________________________ >> 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 rmeggins at redhat.com Mon Nov 25 23:57:37 2013 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 25 Nov 2013 16:57:37 -0700 Subject: [Freeipa-users] IPA winsync replication In-Reply-To: References: <5293694E.9060606@melt.se> <529378EF.3040907@redhat.com> Message-ID: <5293E3F1.3010002@redhat.com> On 11/25/2013 11:51 AM, Emil Petersson wrote: > On 25 Nov 2013, at 17:21, Rich Megginson > wrote: > >> On 11/25/2013 08:14 AM, Emil Petersson wrote: >>> Hi, >>> >>> I'm running FreeIPA 3.0 under RHEL6.4. I'm seeing some unexpected >>> behaviour with winsync replication. >>> >>> 1. I have a working winsync agreement, and users are synced correctly. >>> >>> 2. If a user already exists in in IPA when I sync it from AD, I'm >>> seeing the following in the dirsrv error logs: >>> >>> [25/Nov/2013:14:29:03 +0000] NSMMReplicationPlugin - >>> windows_update_local_entry: failed to modify entry >>> uid=username,cn=users,cn=accounts,dc=domain,dc=net - error >>> 21:Invalid syntax >>> >>> I assume this is because the user already exists in dirsrv? Fine. >> >> No. Error 21 is Invalid Syntax. This means the format of the data >> in the attribute in AD is not correct for the given syntax. For >> example, if the syntax is Integer, this means the data should be a >> valid integer. However, AD allows data that violates LDAP syntax. >> >> Can you post the data from the AD entry that corresponds to >> uid=username,cn=users,cn=accounts,dc=domain,dc=net? Please be sure >> to obscure any sensitive data. I'd like to identify the data that is >> causing this problem. > > Certainly, here goes: > > dn: CN=Firstname > Lastname,OU=LDAP,OU=Domain,OU=Users,OU=Domain,OU=Organization,DC= > domain,DC=com > objectClass: top > objectClass: person > objectClass: organizationalPerson > objectClass: user > cn: Firstname Lastname > sn: Lastname > title: Sysadmin > description: Employee > physicalDeliveryOfficeName: XX-XX-XX > telephoneNumber: +00 00 000 0 > facsimileTelephoneNumber: +00 00 000 0 > givenName: Firstname > distinguishedName: CN=Firstname > Lastname,OU=LDAP,OU=Domain,OU=Users,OU=Domain,OU=O > rganization,DC=domain,DC=com > instanceType: 4 > whenCreated: 20110321122858.0Z > whenChanged: 20131120104224.0Z > displayName: Firstname Lastname > uSNCreated: 76590 > ngame,DC=com > memberOf: CN=All,OU=OrgGroups,OU=Organization,DC=domain,DC=com > memberOf: CN=sysadmins,OU=OrgGroups,OU=Organization,DC=domain,DC=com > uSNChanged: 66378160 > department: Infrastructure > company: Company name > homeMTA: CN=Microsoft MTA,CN=MBX,CN=Servers,CN=Exchange Administrative > Group ( > FYDIBOHF23SPDLT),CN=Administrative Groups,CN=globalmail,CN=Microsoft > Exchange > ,CN=Services,CN=Configuration,DC=domain,DC=com > proxyAddresses: SMTP:first.last at domain.com > proxyAddresses: smtp:first.last at domain2.com > proxyAddresses: smtp:first.last at domain3.com > proxyAddresses: sip:first.last at domain.com > proxyAddresses: X400:C=SE;A= > ;P=globalmail;O=Exchange;S=Lastname;G=Firstname; > homeMDB: CN=DB3,CN=SG03 - > 2GB,CN=InformationStore,CN=MBX,CN=Servers,CN=Exchang > e Administrative Group (FYDIBOHF23SPDLT),CN=Administrative > Groups,CN=globalma > il,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain,DC=com > garbageCollPeriod: 1209600 > mDBUseDefaults: TRUE > extensionAttribute8: Companyname > mailNickname: username > protocolSettings:: SFRUUMKnMcKnMcKnwqfCp8KnwqfCpw== > protocolSettings:: T1dBwqcx > internetEncoding: 0 > name: Firstnam Lastname > objectGUID:: pDdL7yY7gEuqRdQLTjLo0w== > userAccountControl: 512 > badPwdCount: 0 > codePage: 0 > countryCode: 0 > homeDirectory: \\path\to\home > homeDrive: H: > badPasswordTime: 130295283826410995 > lastLogoff: 0 > lastLogon: 130297464093469882 > pwdLastSet: 130294130189116476 > primaryGroupID: 513 > objectSid:: AQUAAAoiadjfojdfojsodijfQkAH5TsrAA== > accountExpires: 0 > logonCount: 6909 > sAMAccountName: username > sAMAccountType: 805306368 > showInAddressBook: CN=Default Global Address List,CN=All Global > Address Lists, > CN=Address Lists Container,CN=globalmail,CN=Microsoft > Exchange,CN=Services,CN > =Configuration,DC=domain,DC=com > showInAddressBook: CN=All Users,CN=All Address Lists,CN=Address Lists > Containe > r,CN=globalmail,CN=Microsoft > Exchange,CN=Services,CN=Configuration,DC=domain, > DC=com > legacyExchangeDN: /o=globalmail/ou=Exchange Administrative Group > (FYDIBOHF23SP > DLT)/cn=Recipients/cn=username > userPrincipalName: first at domain.com > lockoutTime: 0 > ipPhone: +00 00 00 00 > objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=domain,DC=com > dSCorePropagationData: 20131118102944.0Z > dSCorePropagationData: 20131118102934.0Z > dSCorePropagationData: 20130313150036.0Z > dSCorePropagationData: 20120821144903.0Z > dSCorePropagationData: 16010101181216.0Z > lastLogonTimestamp: 130294177442871790 > textEncodedORAddress: c=XX;a= > ;p=globalmail;o=Exchange;s=Lastname;g=Firstname; > mail: first.last at domain.com > manager: CN=Manager Name,OU=Domain,OU=Users,OU=Domain,OU=Organization,DC=o > ngame,DC=com > mobile:: KzQ2NzI3mjMEMTEwwqAJ > thumbnailPhoto:: > /9j/4QAYRXhpZgAASUkqAAgAAAAAAAAAAAAAAP/sABFEdWNreQABAAQAAABkA > -snip- > uaC3IbWlp5cQtpnwnCmjkd9LrDoNFIUDThZwzyrwJbl21//9k= > msExchHomeServerName: /o=globalmail/ou=Exchange Administrative Group > (FYDIBOHF > 23SPDLT)/cn=Configuration/cn=Servers/cn=MBX > msExchMailboxSecurityDescriptor:: > AQAUjBQAAAAgAAAALAAAAFwAAAABAQAAAAAABQoAAAAB > -snip- > AQAAAAAABQoAAAACADAAAgAAAALQFAADAA0AAQEAAAAAAAEAAAAAAtoUAGsBDQABAQAAAAAAAQAAA > msExchUserAccountControl: 0 > msExchMailboxGuid:: uWv8V7HNHUiyda0z/FRc+w== > msExchPoliciesIncluded: > {A64061C3-9598-43A1-9125-B5C682DEDA40},{26491CFC-9E50- > 4857-861B-0CB8DF22B5D7} > msRTCSIP-Line: TEL:+46812136492 > msRTCSIP-DeploymentLocator: SRV: > msExchUserCulture: sv-SE,en-US > msExchMobileMailboxFlags: 1 > msExchRecipientDisplayType: 1073741824 > msExchVersion: 4535486012416 > msRTCSIP-FederationEnabled: TRUE > msRTCSIP-PrimaryUserAddress: sip:first.last at domain.com > msExchRecipientTypeDetails: 1 > msRTCSIP-InternetAccessEnabled: TRUE > msRTCSIP-UserPolicies: 0=481565286 > msExchMDBRulesQuota: 64 > msRTCSIP-OptionFlags: 385 > msRTCSIP-UserEnabled: TRUE > msRTCSIP-PrimaryHomeServer: CN=Lc > Services,CN=Microsoft,CN=1:1,CN=Pools,CN=RTC > Service,CN=Services,CN=Configuration,DC=domain,DC=com > > Please note that the same user would sync OK if I hadn't attempted to > sync it earlier when the duplicate IPA entry was in place. This is the > strangest part... once a user is synced and there's a duplicate in > place, we get error 21 and after that the user will be ignored in > future syncs. Even if we recreate the agreement. > > Question, if a duplicate entry exists in IPA, what's the expected > behaviour? Should the user get synced anyway, or should it fail? It should get synced - it should try to update the entry with any missing or out-of-date information. > > Please let me know if you need anything else. Setting > nsslapd-errorlog-level: 8192 more or less says the same thing... error > 21, and then it just moves on. I could provide you with the debug > though, if wanted. Yes, please. > >> >>> >>> 3. Then I remove the corresponding user from IPA and force another >>> sync from AD, hoping that the user will sync properly this time, and >>> thus have its ntUser* attributes created: >>> >>> [25/Nov/2013:14:29:09 +0000] NSMMReplicationPlugin - >>> agmt="cn=meToAD.domain.com " (dc03:389): >>> map_entry_dn_inbound: looking for local entry by uid [username] >>> [25/Nov/2013:14:29:09 +0000] - Windows sync entry: Adding new >>> local entry dn: uid=username,cn=users,cn=accounts,dc=domain,dc=net >>> [25/Nov/2013:14:29:09 +0000] NSMMReplicationPlugin - add >>> operation of entry >>> uid=username,cn=users,cn=accounts,dc=domain,dc=net returned: 21 >>> >>> It's like something (either AD or IPA) remembers that a user have >>> failed once, and then refuse to sync it any more. Removing the >>> winsync agreement and recreating it completely doesn't help. The >>> user is still not synced, and leaves error code 21. >>> >>> Anyone have any idea on why this is, and how I can sync the user >>> even though it has failed once? > > > > _______________________________________________ > 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 rmeggins at redhat.com Tue Nov 26 00:05:07 2013 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 25 Nov 2013 17:05:07 -0700 Subject: [Freeipa-users] IPA winsync replication In-Reply-To: <5293E3F1.3010002@redhat.com> References: <5293694E.9060606@melt.se> <529378EF.3040907@redhat.com> <5293E3F1.3010002@redhat.com> Message-ID: <5293E5B3.4020106@redhat.com> On 11/25/2013 04:57 PM, Rich Megginson wrote: > On 11/25/2013 11:51 AM, Emil Petersson wrote: >> On 25 Nov 2013, at 17:21, Rich Megginson > > wrote: >> >>> On 11/25/2013 08:14 AM, Emil Petersson wrote: >>>> Hi, >>>> >>>> I'm running FreeIPA 3.0 under RHEL6.4. I'm seeing some unexpected >>>> behaviour with winsync replication. >>>> >>>> 1. I have a working winsync agreement, and users are synced correctly. >>>> >>>> 2. If a user already exists in in IPA when I sync it from AD, I'm >>>> seeing the following in the dirsrv error logs: >>>> >>>> [25/Nov/2013:14:29:03 +0000] NSMMReplicationPlugin - >>>> windows_update_local_entry: failed to modify entry >>>> uid=username,cn=users,cn=accounts,dc=domain,dc=net - error >>>> 21:Invalid syntax >>>> >>>> I assume this is because the user already exists in dirsrv? Fine. >>> >>> No. Error 21 is Invalid Syntax. This means the format of the data >>> in the attribute in AD is not correct for the given syntax. For >>> example, if the syntax is Integer, this means the data should be a >>> valid integer. However, AD allows data that violates LDAP syntax. >>> >>> Can you post the data from the AD entry that corresponds to >>> uid=username,cn=users,cn=accounts,dc=domain,dc=net? Please be sure >>> to obscure any sensitive data. I'd like to identify the data that >>> is causing this problem. >> >> Certainly, here goes: >> >> dn: CN=Firstname >> Lastname,OU=LDAP,OU=Domain,OU=Users,OU=Domain,OU=Organization,DC= >> domain,DC=com >> objectClass: top >> objectClass: person >> objectClass: organizationalPerson >> objectClass: user >> cn: Firstname Lastname >> sn: Lastname >> title: Sysadmin >> description: Employee >> physicalDeliveryOfficeName: XX-XX-XX >> telephoneNumber: +00 00 000 0 >> facsimileTelephoneNumber: +00 00 000 0 >> givenName: Firstname >> distinguishedName: CN=Firstname >> Lastname,OU=LDAP,OU=Domain,OU=Users,OU=Domain,OU=O >> rganization,DC=domain,DC=com >> instanceType: 4 >> whenCreated: 20110321122858.0Z >> whenChanged: 20131120104224.0Z >> displayName: Firstname Lastname >> uSNCreated: 76590 >> ngame,DC=com >> memberOf: CN=All,OU=OrgGroups,OU=Organization,DC=domain,DC=com >> memberOf: CN=sysadmins,OU=OrgGroups,OU=Organization,DC=domain,DC=com >> uSNChanged: 66378160 >> department: Infrastructure >> company: Company name >> homeMTA: CN=Microsoft MTA,CN=MBX,CN=Servers,CN=Exchange >> Administrative Group ( >> FYDIBOHF23SPDLT),CN=Administrative Groups,CN=globalmail,CN=Microsoft >> Exchange >> ,CN=Services,CN=Configuration,DC=domain,DC=com >> proxyAddresses: SMTP:first.last at domain.com >> proxyAddresses: smtp:first.last at domain2.com >> proxyAddresses: smtp:first.last at domain3.com >> proxyAddresses: sip:first.last at domain.com >> proxyAddresses: X400:C=SE;A= >> ;P=globalmail;O=Exchange;S=Lastname;G=Firstname; >> homeMDB: CN=DB3,CN=SG03 - >> 2GB,CN=InformationStore,CN=MBX,CN=Servers,CN=Exchang >> e Administrative Group (FYDIBOHF23SPDLT),CN=Administrative >> Groups,CN=globalma >> il,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain,DC=com >> garbageCollPeriod: 1209600 >> mDBUseDefaults: TRUE >> extensionAttribute8: Companyname >> mailNickname: username >> protocolSettings:: SFRUUMKnMcKnMcKnwqfCp8KnwqfCpw== >> protocolSettings:: T1dBwqcx >> internetEncoding: 0 >> name: Firstnam Lastname >> objectGUID:: pDdL7yY7gEuqRdQLTjLo0w== >> userAccountControl: 512 >> badPwdCount: 0 >> codePage: 0 >> countryCode: 0 >> homeDirectory: \\path\to\home >> homeDrive: H: >> badPasswordTime: 130295283826410995 >> lastLogoff: 0 >> lastLogon: 130297464093469882 >> pwdLastSet: 130294130189116476 >> primaryGroupID: 513 >> objectSid:: AQUAAAoiadjfojdfojsodijfQkAH5TsrAA== >> accountExpires: 0 >> logonCount: 6909 >> sAMAccountName: username >> sAMAccountType: 805306368 >> showInAddressBook: CN=Default Global Address List,CN=All Global >> Address Lists, >> CN=Address Lists Container,CN=globalmail,CN=Microsoft >> Exchange,CN=Services,CN >> =Configuration,DC=domain,DC=com >> showInAddressBook: CN=All Users,CN=All Address Lists,CN=Address Lists >> Containe >> r,CN=globalmail,CN=Microsoft >> Exchange,CN=Services,CN=Configuration,DC=domain, >> DC=com >> legacyExchangeDN: /o=globalmail/ou=Exchange Administrative Group >> (FYDIBOHF23SP >> DLT)/cn=Recipients/cn=username >> userPrincipalName: first at domain.com >> lockoutTime: 0 >> ipPhone: +00 00 00 00 >> objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=domain,DC=com >> dSCorePropagationData: 20131118102944.0Z >> dSCorePropagationData: 20131118102934.0Z >> dSCorePropagationData: 20130313150036.0Z >> dSCorePropagationData: 20120821144903.0Z >> dSCorePropagationData: 16010101181216.0Z >> lastLogonTimestamp: 130294177442871790 >> textEncodedORAddress: c=XX;a= >> ;p=globalmail;o=Exchange;s=Lastname;g=Firstname; >> mail: first.last at domain.com >> manager: CN=Manager >> Name,OU=Domain,OU=Users,OU=Domain,OU=Organization,DC=o >> ngame,DC=com >> mobile:: KzQ2NzI3mjMEMTEwwqAJ I think this may be the problem. mobile contains non printable characters: $ python >>> import base64 >>> base64.b64decode('KzQ2NzI3mjMEMTEwwqAJ') '+46727\x9a3\x04110\xc2\xa0\t' Looks like the mobile phone number contains utf8 characters. It must not: /* Per RFC4517: * * TelephoneNumber = PrintableString * PrintableString = 1*PrintableCharacter */ Unfortunately, AD syntax checking leaves a lot to be desired, so it allows this and other bogus data. IPA/389 is much stricter. >> thumbnailPhoto:: >> /9j/4QAYRXhpZgAASUkqAAgAAAAAAAAAAAAAAP/sABFEdWNreQABAAQAAABkA >> -snip- >> uaC3IbWlp5cQtpnwnCmjkd9LrDoNFIUDThZwzyrwJbl21//9k= >> msExchHomeServerName: /o=globalmail/ou=Exchange Administrative Group >> (FYDIBOHF >> 23SPDLT)/cn=Configuration/cn=Servers/cn=MBX >> msExchMailboxSecurityDescriptor:: >> AQAUjBQAAAAgAAAALAAAAFwAAAABAQAAAAAABQoAAAAB >> -snip- >> AQAAAAAABQoAAAACADAAAgAAAALQFAADAA0AAQEAAAAAAAEAAAAAAtoUAGsBDQABAQAAAAAAAQAAA >> msExchUserAccountControl: 0 >> msExchMailboxGuid:: uWv8V7HNHUiyda0z/FRc+w== >> msExchPoliciesIncluded: >> {A64061C3-9598-43A1-9125-B5C682DEDA40},{26491CFC-9E50- >> 4857-861B-0CB8DF22B5D7} >> msRTCSIP-Line: TEL:+46812136492 >> msRTCSIP-DeploymentLocator: SRV: >> msExchUserCulture: sv-SE,en-US >> msExchMobileMailboxFlags: 1 >> msExchRecipientDisplayType: 1073741824 >> msExchVersion: 4535486012416 >> msRTCSIP-FederationEnabled: TRUE >> msRTCSIP-PrimaryUserAddress: sip:first.last at domain.com >> msExchRecipientTypeDetails: 1 >> msRTCSIP-InternetAccessEnabled: TRUE >> msRTCSIP-UserPolicies: 0=481565286 >> msExchMDBRulesQuota: 64 >> msRTCSIP-OptionFlags: 385 >> msRTCSIP-UserEnabled: TRUE >> msRTCSIP-PrimaryHomeServer: CN=Lc >> Services,CN=Microsoft,CN=1:1,CN=Pools,CN=RTC >> Service,CN=Services,CN=Configuration,DC=domain,DC=com >> >> Please note that the same user would sync OK if I hadn't attempted to >> sync it earlier when the duplicate IPA entry was in place. This is >> the strangest part... once a user is synced and there's a duplicate >> in place, we get error 21 and after that the user will be ignored in >> future syncs. Even if we recreate the agreement. >> >> Question, if a duplicate entry exists in IPA, what's the expected >> behaviour? Should the user get synced anyway, or should it fail? > > It should get synced - it should try to update the entry with any > missing or out-of-date information. > >> >> Please let me know if you need anything else. Setting >> nsslapd-errorlog-level: 8192 more or less says the same thing... >> error 21, and then it just moves on. I could provide you with the >> debug though, if wanted. > > Yes, please. > >> >>> >>>> >>>> 3. Then I remove the corresponding user from IPA and force another >>>> sync from AD, hoping that the user will sync properly this time, >>>> and thus have its ntUser* attributes created: >>>> >>>> [25/Nov/2013:14:29:09 +0000] NSMMReplicationPlugin - >>>> agmt="cn=meToAD.domain.com " (dc03:389): >>>> map_entry_dn_inbound: looking for local entry by uid [username] >>>> [25/Nov/2013:14:29:09 +0000] - Windows sync entry: Adding new >>>> local entry dn: uid=username,cn=users,cn=accounts,dc=domain,dc=net >>>> [25/Nov/2013:14:29:09 +0000] NSMMReplicationPlugin - add >>>> operation of entry >>>> uid=username,cn=users,cn=accounts,dc=domain,dc=net returned: 21 >>>> >>>> It's like something (either AD or IPA) remembers that a user have >>>> failed once, and then refuse to sync it any more. Removing the >>>> winsync agreement and recreating it completely doesn't help. The >>>> user is still not synced, and leaves error code 21. >>>> >>>> Anyone have any idea on why this is, and how I can sync the user >>>> even though it has failed once? >> >> >> >> _______________________________________________ >> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.bryant at melbourneit.com.au Tue Nov 26 01:55:05 2013 From: matthew.bryant at melbourneit.com.au (Matt Bryant) Date: Tue, 26 Nov 2013 11:55:05 +1000 Subject: [Freeipa-users] Intermittent Issues changing passwords since updating to ipa v3 and sasl_bind timeouts .. In-Reply-To: <5293E17E.7040801@melbourneit.com.au> References: <5293E17E.7040801@melbourneit.com.au> Message-ID: <5293FF79.5@melbourneit.com.au> Well its definitely the bind to ldap via GSSAPI thats the issue ... sssd_ (Tue Nov 26 11:34:08 2013) [sssd[be[ipa.server-noc.com]]] [sasl_bind_send] (0x0100): Executing sasl bind mech: GSSAPI, user: host/tardis.ipa.server-noc.com (Tue Nov 26 11:34:14 2013) [sssd[be[ipa.server-noc.com]]] [sasl_bind_send] (0x0020): ldap_sasl_bind failed (-5)[Timed out] (Tue Nov 26 11:34:14 2013) [sssd[be[ipa.server-noc.com]]] [sasl_bind_send] (0x0080): Extended failure message: [unknown error] dirsrv-slapd 26/Nov/2013:11:34:07 +1000] conn=3555 op=1 BIND dn="" method=sasl version=3 mech=GSSAPI [26/Nov/2013:11:34:13 +1000] conn=3555 op=2 UNBIND [26/Nov/2013:11:34:13 +1000] conn=3555 op=2 fd=97 closed - U1 ldp_child (Tue Nov 26 11:34:07 2013) [[sssd[ldap_child[9689]]]] [ldap_child_get_tgt_sync] (0x2000): credentials initialized (Tue Nov 26 11:34:07 2013) [[sssd[ldap_child[9689]]]] [sss_child_krb5_trace_cb] (0x4000): [9689] 1385429647.891977: Initializing FILE:/var/lib/sss/db/ccache_SERVER-IPA with default princ host/tardis.ipa.server-noc.com at SERVER-IPA (Tue Nov 26 11:34:08 2013) [[sssd[ldap_child[9689]]]] [sss_child_krb5_trace_cb] (0x4000): [9689] 1385429648.31633: Removing host/tardis.ipa.server-noc.com at SERVER-IPA -> krbtgt/SERVER-IPA at SERVER-IPA from FILE:/var/lib/sss/db/ccache_SERVER-IPA (Tue Nov 26 11:34:08 2013) [[sssd[ldap_child[9689]]]] [sss_child_krb5_trace_cb] (0x4000): [9689] 1385429648.31677: Storing host/tardis.ipa.server-noc.com at SERVER-IPA -> krbtgt/SERVER-IPA at SERVER-IPA in FILE:/var/lib/sss/db/ccache_SERVER-IPA (Tue Nov 26 11:34:08 2013) [[sssd[ldap_child[9689]]]] [ldap_child_get_tgt_sync] (0x2000): credentials stored (Tue Nov 26 11:34:08 2013) [[sssd[ldap_child[9689]]]] [ldap_child_get_tgt_sync] (0x2000): Got KDC time offset (Tue Nov 26 11:34:08 2013) [[sssd[ldap_child[9689]]]] [prepare_response] (0x0400): Building response for result [0] (Tue Nov 26 11:34:08 2013) [[sssd[ldap_child[9689]]]] [pack_buffer] (0x2000): response size: 58 (Tue Nov 26 11:34:08 2013) [[sssd[ldap_child[9689]]]] [pack_buffer] (0x1000): result [0] krberr [0] msgsize [38] msg [FILE:/var/lib/sss/db/ccache_SERVER-IPA] (Tue Nov 26 11:34:08 2013) [[sssd[ldap_child[9689]]]] [main] (0x0400): ldap_child completed successfully Have even updated config to increase timeout to 10s ldap_network_timeout = 10 ldap_opt_timeout = 10 but even thats timing out .. given the server IS the ipa server that runs the ldap and KDC no way it should be taking so long ... (Tue Nov 26 11:45:36 2013) [sssd[be[ipa.server-noc.com]]] [sasl_bind_send] (0x0100): Executing sasl bind mech: GSSAPI, user: host/tardis.ipa.server-noc.com (Tue Nov 26 11:45:46 2013) [sssd[be[ipa.server-noc.com]]] [sasl_bind_send] (0x0020): ldap_sasl_bind failed (-5)[Timed out] (Tue Nov 26 11:45:46 2013) [sssd[be[ipa.server-noc.com]]] [sasl_bind_send] (0x0080): Extended failure message: [unknown error] kdclog Nov 03 11:45:28 tardis.ipa.server-noc.com krb5kdc[6411](info): AS_REQ (4 etypes {18 17 16 23}) 203.147.190.30: NEEDED_PREAUTH: host/tardis.ipa.server-noc.com at SERVER-IPA for krbtgt/SERVER-IPA at SERVER-IPA, Additional pre-authentication required Nov 03 11:45:28 tardis.ipa.server-noc.com krb5kdc[6410](info): AS_REQ (4 etypes {18 17 16 23}) 203.147.190.30: ISSUE: authtime 1383443128, etypes {rep=18 tkt=18 ses=18}, host/tardis.ipa.server-noc.com at SERVER-IPA for krbtgt/SERVER-IPA at SERVER-IPA Nov 03 11:45:28 tardis.ipa.server-noc.com krb5kdc[6411](info): TGS_REQ (4 etypes {18 17 16 23}) 203.147.190.30: ISSUE: authtime 1383443128, etypes {rep=18 tkt=18 ses=18}, host/tardis.ipa.server-noc.com at SERVER-IPA for ldap/tardis.ipa.server-noc.com at SERVER-IPA So now how to figure out WHY its taking so long to bind to ldap via GSSAPI ... any pointers ?? rgds Matt B. -------- Original Message -------- Subject: Re: [Freeipa-users] Intermittent Issues changing passwords since updating to ipa v3 and sasl_bind timeouts .. Date: Tue, 26 Nov 2013 09:47:10 +1000 From: Matt Bryant To: After some further digging I tend to agree that its in the LDAP arena where the issue lies .. but there is nothing in the ldap_child log thats helping out .. (btw the other replica IPA servers dont seem to encounter this issue just the master (ie the server with CA responsibility) ... Also more logs (sigh) dont understand though how a server can be marked as working and in the same second fail ... or what call is causing an input/output error ... :( (Tue Nov 26 09:14:58 2013) [sssd[be[ipa.server-noc.com]]] [sasl_bind_send] (0x0100): Executing sasl bind mech: GSSAPI, user: host/tardis.ipa.server-noc.com (Tue Nov 26 09:15:04 2013) [sssd[be[ipa.server-noc.com]]] [sasl_bind_send] (0x0020): ldap_sasl_bind failed (-5)[Timed out] (Tue Nov 26 09:15:04 2013) [sssd[be[ipa.server-noc.com]]] [sasl_bind_send] (0x0080): Extended failure message: [unknown error] (Tue Nov 26 09:15:04 2013) [sssd[be[ipa.server-noc.com]]] [fo_set_port_status] (0x0100): Marking port 0 of server 'tardis.ipa.server-noc.com' as 'not working' (Tue Nov 26 09:15:04 2013) [sssd[be[ipa.server-noc.com]]] [sdap_handle_release] (0x2000): Trace: sh[0x17dcf50], connected[1], ops[(nil)], ldap[0x17d6920], destructor_lock[0], release_memory[0] (Tue Nov 26 09:15:04 2013) [sssd[be[ipa.server-noc.com]]] [remove_connection_callback] (0x4000): Successfully removed connection callback. (Tue Nov 26 09:15:04 2013) [sssd[be[ipa.server-noc.com]]] [sdap_id_op_connect_done] (0x4000): notify error to op #1: 5 [Input/output error] (Tue Nov 26 09:15:04 2013) [sssd[be[ipa.server-noc.com]]] [acctinfo_callback] (0x0100): Request processed. Returned 3,5,User lookup failed (Tue Nov 26 09:15:04 2013) [sssd[be[ipa.server-noc.com]]] [sdap_id_release_conn_data] (0x4000): releasing unused connection (Tue Nov 26 09:15:04 2013) [sssd[be[ipa.server-noc.com]]] [sbus_dispatch] (0x4000): dbus conn: 174A470 (Tue Nov 26 09:15:04 2013) [sssd[be[ipa.server-noc.com]]] [sbus_dispatch] (0x4000): Dispatching. (Tue Nov 26 09:15:04 2013) [sssd[be[ipa.server-noc.com]]] [sbus_message_handler] (0x4000): Received SBUS method [getAccountInfo] (Tue Nov 26 09:15:04 2013) [sssd[be[ipa.server-noc.com]]] [be_get_account_info] (0x0100): Got request for [4097][1][name=nobody] (Tue Nov 26 09:15:04 2013) [sssd[be[ipa.server-noc.com]]] [sdap_id_op_connect_step] (0x4000): beginning to connect (Tue Nov 26 09:15:04 2013) [sssd[be[ipa.server-noc.com]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' (Tue Nov 26 09:15:04 2013) [sssd[be[ipa.server-noc.com]]] [get_server_status] (0x1000): Status of server 'tardis.ipa.server-noc.com' is 'working' (Tue Nov 26 09:15:04 2013) [sssd[be[ipa.server-noc.com]]] [get_port_status] (0x1000): Port status of port 0 for server 'tardis.ipa.server-noc.com' is 'not working' (Tue Nov 26 09:15:04 2013) [sssd[be[ipa.server-noc.com]]] [fo_resolve_service_send] (0x0020): No available servers for service 'IPA' (Tue Nov 26 09:15:04 2013) [sssd[be[ipa.server-noc.com]]] [be_resolve_server_done] (0x1000): Server resolution failed: 5 (Tue Nov 26 09:15:04 2013) [sssd[be[ipa.server-noc.com]]] [sdap_id_op_connect_done] (0x0020): Failed to connect, going offline (5 [Input/output error]) (Tue Nov 26 09:15:04 2013) [sssd[be[ipa.server-noc.com]]] [be_mark_offline] (0x2000): Going offline! (Tue Nov 26 09:15:04 2013) [sssd[be[ipa.server-noc.com]]] [be_run_offline_cb] (0x0080): Going offline. Running callbacks. (Tue Nov 26 09:15:04 2013) [sssd[be[ipa.server-noc.com]]] [sdap_id_op_connect_done] (0x4000): notify offline to op #1 (Tue Nov 26 09:15:04 2013) [sssd[be[ipa.server-noc.com]]] [acctinfo_callback] (0x0100): Request processed. Returned 1,11,Offline (Tue Nov 26 09:15:04 2013) [sssd[be[ipa.server-noc.com]]] [sdap_id_release_conn_data] (0x4000): releasing unused connection ... ... (Tue Nov 26 09:16:12 2013) [sssd[be[ipa.server-noc.com]]] [sbus_dispatch] (0x4000): dbus conn: 171FDB0 (Tue Nov 26 09:16:12 2013) [sssd[be[ipa.server-noc.com]]] [sbus_dispatch] (0x4000): Dispatching. (Tue Nov 26 09:16:12 2013) [sssd[be[ipa.server-noc.com]]] [sbus_message_handler] (0x4000): Received SBUS method [ping] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sbus_dispatch] (0x4000): dbus conn: 174A470 (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sbus_dispatch] (0x4000): Dispatching. (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sbus_message_handler] (0x4000): Received SBUS method [getAccountInfo] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [be_get_account_info] (0x0100): Got request for [4097][1][idnumber=493] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [be_get_account_info] (0x0100): Request processed. Returned 1,11,Fast reply - offline (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_id_op_connect_step] (0x4000): beginning to connect (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [get_server_status] (0x1000): Status of server 'tardis.ipa.server-noc.com' is 'working' (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [get_port_status] (0x1000): Port status of port 0 for server 'tardis.ipa.server-noc.com' is 'not working' (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [get_port_status] (0x0100): Reseting the status of port 0 for server 'tardis.ipa.server-noc.com' (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set to 10 seconds (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [get_server_status] (0x1000): Status of server 'tardis.ipa.server-noc.com' is 'working' (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [be_resolve_server_process] (0x1000): Saving the first resolved server (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [be_resolve_server_process] (0x0200): Found address for server tardis.ipa.server-noc.com: [203.147.190.30] TTL 7200 (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [ipa_resolve_callback] (0x0400): Constructed uri 'ldap://tardis.ipa.server-noc.com' (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sss_ldap_init_send] (0x4000): Using file descriptor [19] for LDAP connection. (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sss_ldap_init_send] (0x0400): Setting 10 seconds timeout for connecting (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_ldap_connect_callback_add] (0x1000): New LDAP connection to [ldap://tardis.ipa.server-noc.com:389/??base] with fd [19]. (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_rootdse_send] (0x4000): Getting rootdse (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(objectclass=*)][]. (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [*] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [altServer] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [namingContexts] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedControl] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedExtension] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedFeatures] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedLDAPVersion] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedSASLMechanisms] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [domainControllerFunctionality] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [defaultNamingContext] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [lastUSN] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [highestCommittedUSN] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 1 (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sbus_dispatch] (0x4000): dbus conn: 174A470 (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sbus_dispatch] (0x4000): Dispatching. (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sbus_message_handler] (0x4000): Received SBUS method [getAccountInfo] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [be_get_account_info] (0x0100): Got request for [4097][1][*] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_process_result] (0x2000): Trace: sh[0x171e770], connected[1], ops[0x17dded0], ldap[0x17378e0] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_parse_entry] (0x4000): OriginalDN: []. (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectClass] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [namingContexts] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [defaultnamingcontext] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [supportedExtension] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [supportedControl] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [supportedSASLMechanisms] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [supportedLDAPVersion] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [vendorName] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [vendorVersion] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [dataversion] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [netscapemdsuffix] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [lastusn] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_process_result] (0x2000): Trace: sh[0x171e770], connected[1], ops[0x17dded0], ldap[0x17378e0] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_rootdse_done] (0x2000): Got rootdse (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_rootdse_done] (0x2000): Skipping auto-detection of match rule (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_server_opts_from_rootdse] (0x4000): USN value: 7097911 (int: 7097911) (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_kinit_send] (0x0400): Attempting kinit (default, host/tardis.ipa.server-noc.com, SERVER-IPA, 86400) (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_kinit_next_kdc] (0x1000): Resolving next KDC for service IPA (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [get_server_status] (0x1000): Status of server 'tardis.ipa.server-noc.com' is 'working' (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set to 10 seconds (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [get_server_status] (0x1000): Status of server 'tardis.ipa.server-noc.com' is 'working' (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [be_resolve_server_process] (0x1000): Saving the first resolved server (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [be_resolve_server_process] (0x0200): Found address for server tardis.ipa.server-noc.com: [203.147.190.30] TTL 7200 (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_kinit_kdc_resolved] (0x1000): KDC resolved, attempting to get TGT... (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [create_tgt_req_send_buffer] (0x1000): buffer size: 56 (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [child_handler_setup] (0x2000): Setting up signal handler up for pid [26046] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [child_handler_setup] (0x2000): Signal handler set up for pid [26046] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [set_tgt_child_timeout] (0x0400): Setting 6 seconds timeout for tgt child (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_process_result] (0x2000): Trace: sh[0x171e770], connected[1], ops[(nil)], ldap[0x17378e0] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [write_pipe_handler] (0x0400): All data has been sent! (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sbus_dispatch] (0x4000): dbus conn: 174A470 (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sbus_dispatch] (0x4000): Dispatching. (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sbus_message_handler] (0x4000): Received SBUS method [getAccountInfo] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [be_get_account_info] (0x0100): Got request for [4098][1][*] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sbus_dispatch] (0x4000): dbus conn: 174A470 (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sbus_dispatch] (0x4000): Dispatching. (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sbus_message_handler] (0x4000): Received SBUS method [getAccountInfo] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [be_get_account_info] (0x0100): Got request for [4097][1][idnumber=493] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_id_op_connect_step] (0x4000): waiting for connection to complete (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sbus_dispatch] (0x4000): dbus conn: 171FDB0 (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sbus_dispatch] (0x4000): Dispatching. (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sbus_message_handler] (0x4000): Received SBUS method [ping] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [child_sig_handler] (0x1000): Waiting for child [26046]. (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [child_sig_handler] (0x0100): child [26046] finished successfully. (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sss_child_handler] (0x2000): waitpid failed [10]: No child processes (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [read_pipe_handler] (0x0400): EOF received, client finished (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_tgt_recv] (0x0400): Child responded: 0 [FILE:/var/lib/sss/db/ccache_SERVER-IPA], expired on [1385507781] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_cli_auth_step] (0x0100): expire timeout is 900 (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_cli_auth_step] (0x1000): the connection will expire at 1385422282 (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sasl_bind_send] (0x0100): Executing sasl bind mech: GSSAPI, user: host/tardis.ipa.server-noc.com (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [fo_set_port_status] (0x0100): Marking port 0 of server 'tardis.ipa.server-noc.com' as 'working' (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [set_server_common_status] (0x0100): Marking server 'tardis.ipa.server-noc.com' as 'working' (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_id_op_connect_done] (0x2000): Old USN: 7097881, New USN: 7097911 (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_id_op_connect_done] (0x4000): notify connected to op #1 (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_users_next_base] (0x0400): Searching for users with base [cn=accounts,dc=server-ipa] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(uidNumber=493)(objectclass=posixAccount))][cn=accounts,dc=server-ipa]. (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uid] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userPassword] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uidNumber] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gidNumber] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gecos] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [homeDirectory] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginShell] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [krbPrincipalName] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberOf] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [nsUniqueId] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [modifyTimestamp] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [entryUSN] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowLastChange] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowMin] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowMax] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowWarning] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowInactive] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowExpire] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowFlag] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [krbLastPwdChange] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [krbPasswordExpiration] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [pwdAttribute] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [authorizedService] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [accountExpires] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userAccountControl] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [nsAccountLock] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [host] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginDisabled] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginExpirationTime] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginAllowedTimeMap] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaSshPubKey] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 5 (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_id_op_connect_done] (0x4000): notify connected to op #2 (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_users_next_base] (0x0400): Searching for users with base [cn=accounts,dc=server-ipa] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(uidNumber=493)(objectclass=posixAccount))][cn=accounts,dc=server-ipa]. (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uid] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userPassword] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uidNumber] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gidNumber] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gecos] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [homeDirectory] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginShell] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [krbPrincipalName] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberOf] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [nsUniqueId] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [modifyTimestamp] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [entryUSN] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowLastChange] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowMin] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowMax] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowWarning] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowInactive] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowExpire] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowFlag] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [krbLastPwdChange] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [krbPasswordExpiration] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [pwdAttribute] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [authorizedService] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [accountExpires] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userAccountControl] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [nsAccountLock] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [host] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginDisabled] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginExpirationTime] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginAllowedTimeMap] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaSshPubKey] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 6 (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_id_op_connect_done] (0x4000): caching successful connection after 2 notifies (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [be_run_online_cb] (0x0080): Going online. Running callbacks. (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sbus_dispatch] (0x4000): dbus conn: 174A470 (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sbus_dispatch] (0x4000): Dispatching. (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sbus_message_handler] (0x4000): Received SBUS method [getAccountInfo] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [be_get_account_info] (0x0100): Got request for [4097][1][idnumber=495] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_users_next_base] (0x0400): Searching for users with base [cn=accounts,dc=server-ipa] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(uidNumber=495)(objectclass=posixAccount))][cn=accounts,dc=server-ipa]. (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uid] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userPassword] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uidNumber] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gidNumber] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gecos] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [homeDirectory] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginShell] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [krbPrincipalName] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberOf] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [nsUniqueId] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [modifyTimestamp] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [entryUSN] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowLastChange] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowMin] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowMax] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowWarning] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowInactive] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowExpire] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowFlag] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [krbLastPwdChange] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [krbPasswordExpiration] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [pwdAttribute] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [authorizedService] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [accountExpires] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userAccountControl] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [nsAccountLock] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [host] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginDisabled] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginExpirationTime] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginAllowedTimeMap] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaSshPubKey] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 7 (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [objectclass=ipaNTTrustedDomain][cn=trusts,dc=server-ipa]. (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaNTFlatName] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaNTTrustedDomainSID] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 8 (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [delayed_online_authentication_callback] (0x0200): Backend is online, starting delayed online authentication. also seeing these errors ... Tue Nov 26 09:42:02 2013) [sssd[be[ipa.server-noc.com]]] [ldb] (0x4000): start ldb transaction (nesting: 0) (Tue Nov 26 09:42:02 2013) [sssd[be[ipa.server-noc.com]]] [sysdb_update_ranges] (0x0400): Adding range [SERVER-IPA_id_range]. (Tue Nov 26 09:42:02 2013) [sssd[be[ipa.server-noc.com]]] [sysdb_range_create] (0x0040): Invalid range, expected that either the secondary base rid or the SID of the trusted domain is set, but not both or none of them. (Tue Nov 26 09:42:02 2013) [sssd[be[ipa.server-noc.com]]] [sysdb_range_create] (0x0400): Error: 22 (Invalid argument) (Tue Nov 26 09:42:02 2013) [sssd[be[ipa.server-noc.com]]] [sysdb_update_ranges] (0x0040): sysdb_range_create failed. (Tue Nov 26 09:42:02 2013) [sssd[be[ipa.server-noc.com]]] [ldb] (0x4000): cancel ldb transaction (nesting: 0) (Tue Nov 26 09:42:02 2013) [sssd[be[ipa.server-noc.com]]] [ipa_subdomains_handler_ranges_done] (0x0040): sysdb_update_ranges failed. Have not setup any AD trusts etc ... rgds Matt B. On 11/25/2013 06:49 PM, Sumit Bose wrote: > On Mon, Nov 25, 2013 at 09:23:22AM +1000, Matt Bryant wrote: >> All, >> >> Was wondering if anyone can help out or point us the in right >> direction. Ever since we updated from IPA v2.1 to IPA v3.0 have been >> seeing some intermittent errors when trying to change passwords etc. >> Getting the error cannot change password since system offline. >> >> Have increased the logging and found that quite frequently the >> sasl_bind using the host principle is timing out and failing ... >> (whether this is red herring or not dont know but cant be good >> anyhow) >> >> (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] >> [sdap_kinit_send] (0x0400): Attempting kinit (default, >> host/tardis.ipa.server-noc.com, SERVER-IPA, 86400) >> (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] >> [sdap_kinit_next_kdc] (0x1000): Resolving next KDC for service IPA >> (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] >> [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' >> (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] >> [get_server_status] (0x1000): Status of server >> 'tardis.ipa.server-noc.com' is 'working' >> (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] >> [fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set >> to 10 seconds >> (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] >> [get_server_status] (0x1000): Status of server >> 'tardis.ipa.server-noc.com' is 'working' >> (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] >> [be_resolve_server_process] (0x1000): Saving the first resolved >> server >> (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] >> [be_resolve_server_process] (0x0200): Found address for server >> tardis.ipa.server-noc.com: [203.147.190.30] TTL 7200 >> (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] >> [sdap_kinit_kdc_resolved] (0x1000): KDC resolved, attempting to get >> TGT... >> (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] >> [create_tgt_req_send_buffer] (0x1000): buffer size: 56 >> (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] >> [child_handler_setup] (0x2000): Setting up signal handler up for pid >> [3734] >> (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] >> [child_handler_setup] (0x2000): Signal handler set up for pid [3734] >> (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] >> [set_tgt_child_timeout] (0x0400): Setting 6 seconds timeout for tgt >> child >> (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] >> [sdap_process_result] (0x2000): Trace: sh[0xa45960], connected[1], >> ops[(nil)], ldap[0xa12200] >> (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] >> [sdap_process_result] (0x2000): Trace: ldap_result found nothing! >> (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] >> [write_pipe_handler] (0x0400): All data has been sent! >> (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] >> [child_sig_handler] (0x1000): Waiting for child [3734]. >> (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] >> [child_sig_handler] (0x0100): child [3734] finished successfully. >> (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] >> [sss_child_handler] (0x2000): waitpid failed [10]: No child >> processes >> (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] >> [read_pipe_handler] (0x0400): EOF received, client finished >> (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] >> [sdap_get_tgt_recv] (0x0400): Child responded: 0 >> [FILE:/var/lib/sss/db/ccache_SERVER-IPA], expired on [1385420045] >> (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] >> [sdap_cli_auth_step] (0x0100): expire timeout is 900 >> (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] >> [sdap_cli_auth_step] (0x1000): the connection will expire at >> 1385334545 >> (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] >> [sasl_bind_send] (0x0100): Executing sasl bind mech: GSSAPI, user: >> host/tardis.ipa.server-noc.com >> (Mon Nov 25 08:54:11 2013) [sssd[be[ipa.server-noc.com]]] >> [sasl_bind_send] (0x0020): ldap_sasl_bind failed (-5)[Timed out] >> (Mon Nov 25 08:54:11 2013) [sssd[be[ipa.server-noc.com]]] >> [sasl_bind_send] (0x0080): Extended failure message: [unknown error] >> (Mon Nov 25 08:54:11 2013) [sssd[be[ipa.server-noc.com]]] >> [fo_set_port_status] (0x0100): Marking port 0 of server >> 'tardis.ipa.server-noc.com' as 'not working' >> (Mon Nov 25 08:54:11 2013) [sssd[be[ipa.server-noc.com]]] >> [sdap_handle_release] (0x2000): Trace: sh[0xa45960], connected[1], >> ops[(nil)], ldap[0xa12200], destructor_lock[0], release_memory[0] >> .. >> .. >> >> it then goes on to connect to fail over server and succeed and >> shortly after the master server is tested and marked as working >> again ... works for a couple of times then time out again .. any >> pointers gratefully received. > According to the logs I would say that this timeout happens on the > LDAP server side. Do you have a chance to check the server logs to see > what happens at this time on the server? > > You can increase the timeout value on the client by setting > ldap_opt_timeout to a larger value then 6 (the default). But please note > that the operation might take longer then letting SSSD fail over to the > next server. > > HTH > > bye, > Sumit > >> >> packages used ... >> >> ipa-server-3.0.0-25.el6.x86_64 >> sssd-1.9.2-82.11.el6_4.x86_64 >> >> rgds >> >> Matt Bryant >> >> _______________________________________________ >> 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 _______________________________________________ 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 matthew.bryant at melbourneit.com.au Tue Nov 26 05:07:30 2013 From: matthew.bryant at melbourneit.com.au (Matt Bryant) Date: Tue, 26 Nov 2013 15:07:30 +1000 Subject: [Freeipa-users] Intermittent Issues changing passwords since updating to ipa v3 and sasl_bind timeouts .. In-Reply-To: <5293FF79.5@melbourneit.com.au> References: <5293FF79.5@melbourneit.com.au> Message-ID: <52942C92.1040003@melbourneit.com.au> OK so been running some tcpdumps on this issue and the wierd thing is .. can see the initial sasl bind request followed by ack from ldap ... then nothing ldap/gssapi related until the unbind request post the 6s timeout period ... so no friggin idea whats going on just a big resounding nothing ... 14:20:47.065606 IP tardis.ipa.server-noc.com.40953 > tardis.ipa.server-noc.com.ldap: Flags [P.], seq 261:974, ack 1502, win 280, options [nop,nop,TS val 23677005 ecr 23676785], length 713 14:20:47.104816 IP tardis.ipa.server-noc.com.ldap > tardis.ipa.server-noc.com.40953: Flags [.], ack 974, win 276, options [nop,nop,TS val 23677045 ecr 23677005], length 0 14:20:53.066009 IP tardis.ipa.server-noc.com.40953 > tardis.ipa.server-noc.com.ldap: Flags [P.], seq 974:981, ack 1502, win 280, options [nop,nop,TS val 23683006 ecr 23677045], length 7 14:20:53.066021 IP tardis.ipa.server-noc.com.ldap > tardis.ipa.server-noc.com.40953: Flags [.], ack 981, win 276, options [nop,nop,TS val 23683006 ecr 23683006], length 0 14:20:53.066100 IP tardis.ipa.server-noc.com.40953 > tardis.ipa.server-noc.com.ldap: Flags [F.], seq 981, ack 1502, win 280, options [nop,nop,TS val 23683006 ecr 23683006], length 0 14:20:53.105731 IP tardis.ipa.server-noc.com.ldap > tardis.ipa.server-noc.com.40953: Flags [.], ack 982, win 276, options [nop,nop,TS val 23683046 ecr 23683006], length 0 14:20:53.111470 IP tardis.ipa.server-noc.com.ldap > tardis.ipa.server-noc.com.40953: Flags [F.], seq 1502, ack 982, win 276, options [nop,nop,TS val 23683051 ecr 23683006], length 0 14:20:53.111486 IP tardis.ipa.server-noc.com.40953 > tardis.ipa.server-noc.com.ldap: Flags [.], ack 1503, win 280, options [nop,nop,TS val 23683051 ecr 23683051], length 0 Comparing that to a connection that works and brings the backend online .. 14:22:01.193809 IP tardis.ipa.server-noc.com.41031 > tardis.ipa.server-noc.com.ldap: Flags [S], seq 3387425755, win 32792, options [mss 16396,sackOK,TS val 23751134 ecr 0,nop,wscale 7], length 0 14:22:01.193833 IP tardis.ipa.server-noc.com.ldap > tardis.ipa.server-noc.com.41031: Flags [S.], seq 1024653772, ack 3387425756, win 32768, options [mss 16396,sackOK,TS val 23751134 ecr 23751134,nop,wscale 7], length 0 14:22:01.193848 IP tardis.ipa.server-noc.com.41031 > tardis.ipa.server-noc.com.ldap: Flags [.], ack 1, win 257, options [nop,nop,TS val 23751134 ecr 23751134], length 0 14:22:01.194371 IP tardis.ipa.server-noc.com.41031 > tardis.ipa.server-noc.com.ldap: Flags [P.], seq 1:261, ack 1, win 257, options [nop,nop,TS val 23751134 ecr 23751134], length 260 14:22:01.194385 IP tardis.ipa.server-noc.com.ldap > tardis.ipa.server-noc.com.41031: Flags [.], ack 261, win 265, options [nop,nop,TS val 23751134 ecr 23751134], length 0 14:22:01.195187 IP tardis.ipa.server-noc.com.ldap > tardis.ipa.server-noc.com.41031: Flags [P.], seq 1:1502, ack 261, win 265, options [nop,nop,TS val 23751135 ecr 23751134], length 1501 14:22:01.195201 IP tardis.ipa.server-noc.com.41031 > tardis.ipa.server-noc.com.ldap: Flags [.], ack 1502, win 280, options [nop,nop,TS val 23751135 ecr 23751135], length 0 14:22:01.443288 IP tardis.ipa.server-noc.com.41031 > tardis.ipa.server-noc.com.ldap: Flags [P.], seq 261:953, ack 1502, win 280, options [nop,nop,TS val 23751383 ecr 23751135], length 692 14:22:01.470047 IP tardis.ipa.server-noc.com.ldap > tardis.ipa.server-noc.com.41031: Flags [P.], seq 1502:1677, ack 953, win 276, options [nop,nop,TS val 23751410 ecr 23751383], length 175 14:22:01.470062 IP tardis.ipa.server-noc.com.41031 > tardis.ipa.server-noc.com.ldap: Flags [.], ack 1677, win 304, options [nop,nop,TS val 23751410 ecr 23751410], length 0 14:22:01.470469 IP tardis.ipa.server-noc.com.41031 > tardis.ipa.server-noc.com.ldap: Flags [P.], seq 953:975, ack 1677, win 304, options [nop,nop,TS val 23751410 ecr 23751410], length 22 14:22:01.471249 IP tardis.ipa.server-noc.com.ldap > tardis.ipa.server-noc.com.41031: Flags [P.], seq 1677:1725, ack 975, win 276, options [nop,nop,TS val 23751411 ecr 23751410], length 48 14:22:01.471298 IP tardis.ipa.server-noc.com.41031 > tardis.ipa.server-noc.com.ldap: Flags [P.], seq 975:1031, ack 1725, win 304, options [nop,nop,TS val 23751411 ecr 23751411], length 56 14:22:01.484334 IP tardis.ipa.server-noc.com.ldap > tardis.ipa.server-noc.com.41031: Flags [P.], seq 1725:1739, ack 1031, win 276, options [nop,nop,TS val 23751424 ecr 23751411], length 14 14:22:01.485505 IP tardis.ipa.server-noc.com.41031 > tardis.ipa.server-noc.com.ldap: Flags [P.], seq 1031:1656, ack 1739, win 304, options [nop,nop,TS val 23751425 ecr 23751424], length 625 14:22:01.486736 IP tardis.ipa.server-noc.com.41031 > tardis.ipa.server-noc.com.ldap: Flags [P.], seq 1656:2284, ack 1739, win 304, options [nop,nop,TS val 23751427 ecr 23751424], length 628 14:22:01.486747 IP tardis.ipa.server-noc.com.ldap > tardis.ipa.server-noc.com.41031: Flags [.], ack 2284, win 297, options [nop,nop,TS val 23751427 ecr 23751425], length 0 14:22:01.516185 IP tardis.ipa.server-noc.com.41031 > tardis.ipa.server-noc.com.ldap: Flags [P.], seq 2284:2474, ack 1739, win 304, options [nop,nop,TS val 23751456 ecr 23751427], length 190 14:22:01.555664 IP tardis.ipa.server-noc.com.ldap > tardis.ipa.server-noc.com.41031: Flags [.], ack 2474, win 308, options [nop,nop,TS val 23751496 ecr 23751456], length 0 14:22:07.487451 IP tardis.ipa.server-noc.com.41031 > tardis.ipa.server-noc.com.ldap: Flags [P.], seq 2474:2546, ack 1739, win 304, options [nop,nop,TS val 23757427 ecr 23751496], length 72 14:22:07.487467 IP tardis.ipa.server-noc.com.ldap > tardis.ipa.server-noc.com.41031: Flags [.], ack 2546, win 308, options [nop,nop,TS val 23757427 ecr 23757427], length 0 14:22:07.487983 IP tardis.ipa.server-noc.com.41031 > tardis.ipa.server-noc.com.ldap: Flags [P.], seq 2546:2618, ack 1739, win 304, options [nop,nop,TS val 23757428 ecr 23757427], length 72 14:22:07.487994 IP tardis.ipa.server-noc.com.ldap > tardis.ipa.server-noc.com.41031: Flags [.], ack 2618, win 308, options [nop,nop,TS val 23757428 ecr 23757428], length 0 14:22:07.516863 IP tardis.ipa.server-noc.com.41031 > tardis.ipa.server-noc.com.ldap: Flags [P.], seq 2618:2690, ack 1739, win 304, options [nop,nop,TS val 23757457 ecr 23757428], length 72 14:22:07.516883 IP tardis.ipa.server-noc.com.ldap > tardis.ipa.server-noc.com.41031: Flags [.], ack 2690, win 308, options [nop,nop,TS val 23757457 ecr 23757457], length 0 14:22:07.517102 IP tardis.ipa.server-noc.com.41031 > tardis.ipa.server-noc.com.ldap: Flags [P.], seq 2690:2761, ack 1739, win 304, options [nop,nop,TS val 23757457 ecr 23757457], length 71 14:22:07.517116 IP tardis.ipa.server-noc.com.ldap > tardis.ipa.server-noc.com.41031: Flags [.], ack 2761, win 308, options [nop,nop,TS val 23757457 ecr 23757457], length 0 14:22:07.517573 IP tardis.ipa.server-noc.com.41031 > tardis.ipa.server-noc.com.ldap: Flags [F.], seq 2761, ack 1739, win 304, options [nop,nop,TS val 23757457 ecr 23757457], length 0 14:22:07.556841 IP tardis.ipa.server-noc.com.ldap > tardis.ipa.server-noc.com.41031: Flags [.], ack 2762, win 308, options [nop,nop,TS val 23757497 ecr 23757457], length 0 14:22:13.497311 IP tardis.ipa.server-noc.com.ldap > tardis.ipa.server-noc.com.41031: Flags [P.], seq 1739:1817, ack 2762, win 308, options [nop,nop,TS val 23763437 ecr 23757457], length 78 14:22:13.497333 IP tardis.ipa.server-noc.com.41031 > tardis.ipa.server-noc.com.ldap: Flags [R], seq 3387428517, win 0, length 0 14:22:13.526895 IP tardis.ipa.server-noc.com.ldap > tardis.ipa.server-noc.com.41031: Flags [R.], seq 1817, ack 2762, win 308, options [nop,nop,TS val 23763467 ecr 23757457], length 0 which using the ol' wireshark relate to bind request with a bind response traversing back and fro from ldap server till a bind success from ldap server and the query/queries run .. so to me it seems that there are times (and quite a few of them) where a bind request gets no response back from the server ... Has anyone seen this ... rgds Matt B. -------- Original Message -------- Subject: Re: [Freeipa-users] Intermittent Issues changing passwords since updating to ipa v3 and sasl_bind timeouts .. Date: Tue, 26 Nov 2013 11:55:05 +1000 From: Matt Bryant To: freeipa-users at redhat.com Well its definitely the bind to ldap via GSSAPI thats the issue ... sssd_ (Tue Nov 26 11:34:08 2013) [sssd[be[ipa.server-noc.com]]] [sasl_bind_send] (0x0100): Executing sasl bind mech: GSSAPI, user: host/tardis.ipa.server-noc.com (Tue Nov 26 11:34:14 2013) [sssd[be[ipa.server-noc.com]]] [sasl_bind_send] (0x0020): ldap_sasl_bind failed (-5)[Timed out] (Tue Nov 26 11:34:14 2013) [sssd[be[ipa.server-noc.com]]] [sasl_bind_send] (0x0080): Extended failure message: [unknown error] dirsrv-slapd 26/Nov/2013:11:34:07 +1000] conn=3555 op=1 BIND dn="" method=sasl version=3 mech=GSSAPI [26/Nov/2013:11:34:13 +1000] conn=3555 op=2 UNBIND [26/Nov/2013:11:34:13 +1000] conn=3555 op=2 fd=97 closed - U1 ldp_child (Tue Nov 26 11:34:07 2013) [[sssd[ldap_child[9689]]]] [ldap_child_get_tgt_sync] (0x2000): credentials initialized (Tue Nov 26 11:34:07 2013) [[sssd[ldap_child[9689]]]] [sss_child_krb5_trace_cb] (0x4000): [9689] 1385429647.891977: Initializing FILE:/var/lib/sss/db/ccache_SERVER-IPA with default princ host/tardis.ipa.server-noc.com at SERVER-IPA (Tue Nov 26 11:34:08 2013) [[sssd[ldap_child[9689]]]] [sss_child_krb5_trace_cb] (0x4000): [9689] 1385429648.31633: Removing host/tardis.ipa.server-noc.com at SERVER-IPA -> krbtgt/SERVER-IPA at SERVER-IPA from FILE:/var/lib/sss/db/ccache_SERVER-IPA (Tue Nov 26 11:34:08 2013) [[sssd[ldap_child[9689]]]] [sss_child_krb5_trace_cb] (0x4000): [9689] 1385429648.31677: Storing host/tardis.ipa.server-noc.com at SERVER-IPA -> krbtgt/SERVER-IPA at SERVER-IPA in FILE:/var/lib/sss/db/ccache_SERVER-IPA (Tue Nov 26 11:34:08 2013) [[sssd[ldap_child[9689]]]] [ldap_child_get_tgt_sync] (0x2000): credentials stored (Tue Nov 26 11:34:08 2013) [[sssd[ldap_child[9689]]]] [ldap_child_get_tgt_sync] (0x2000): Got KDC time offset (Tue Nov 26 11:34:08 2013) [[sssd[ldap_child[9689]]]] [prepare_response] (0x0400): Building response for result [0] (Tue Nov 26 11:34:08 2013) [[sssd[ldap_child[9689]]]] [pack_buffer] (0x2000): response size: 58 (Tue Nov 26 11:34:08 2013) [[sssd[ldap_child[9689]]]] [pack_buffer] (0x1000): result [0] krberr [0] msgsize [38] msg [FILE:/var/lib/sss/db/ccache_SERVER-IPA] (Tue Nov 26 11:34:08 2013) [[sssd[ldap_child[9689]]]] [main] (0x0400): ldap_child completed successfully Have even updated config to increase timeout to 10s ldap_network_timeout = 10 ldap_opt_timeout = 10 but even thats timing out .. given the server IS the ipa server that runs the ldap and KDC no way it should be taking so long ... (Tue Nov 26 11:45:36 2013) [sssd[be[ipa.server-noc.com]]] [sasl_bind_send] (0x0100): Executing sasl bind mech: GSSAPI, user: host/tardis.ipa.server-noc.com (Tue Nov 26 11:45:46 2013) [sssd[be[ipa.server-noc.com]]] [sasl_bind_send] (0x0020): ldap_sasl_bind failed (-5)[Timed out] (Tue Nov 26 11:45:46 2013) [sssd[be[ipa.server-noc.com]]] [sasl_bind_send] (0x0080): Extended failure message: [unknown error] kdclog Nov 03 11:45:28 tardis.ipa.server-noc.com krb5kdc[6411](info): AS_REQ (4 etypes {18 17 16 23}) 203.147.190.30: NEEDED_PREAUTH: host/tardis.ipa.server-noc.com at SERVER-IPA for krbtgt/SERVER-IPA at SERVER-IPA, Additional pre-authentication required Nov 03 11:45:28 tardis.ipa.server-noc.com krb5kdc[6410](info): AS_REQ (4 etypes {18 17 16 23}) 203.147.190.30: ISSUE: authtime 1383443128, etypes {rep=18 tkt=18 ses=18}, host/tardis.ipa.server-noc.com at SERVER-IPA for krbtgt/SERVER-IPA at SERVER-IPA Nov 03 11:45:28 tardis.ipa.server-noc.com krb5kdc[6411](info): TGS_REQ (4 etypes {18 17 16 23}) 203.147.190.30: ISSUE: authtime 1383443128, etypes {rep=18 tkt=18 ses=18}, host/tardis.ipa.server-noc.com at SERVER-IPA for ldap/tardis.ipa.server-noc.com at SERVER-IPA So now how to figure out WHY its taking so long to bind to ldap via GSSAPI ... any pointers ?? rgds Matt B. -------- Original Message -------- Subject: Re: [Freeipa-users] Intermittent Issues changing passwords since updating to ipa v3 and sasl_bind timeouts .. Date: Tue, 26 Nov 2013 09:47:10 +1000 From: Matt Bryant To: After some further digging I tend to agree that its in the LDAP arena where the issue lies .. but there is nothing in the ldap_child log thats helping out .. (btw the other replica IPA servers dont seem to encounter this issue just the master (ie the server with CA responsibility) ... Also more logs (sigh) dont understand though how a server can be marked as working and in the same second fail ... or what call is causing an input/output error ... :( (Tue Nov 26 09:14:58 2013) [sssd[be[ipa.server-noc.com]]] [sasl_bind_send] (0x0100): Executing sasl bind mech: GSSAPI, user: host/tardis.ipa.server-noc.com (Tue Nov 26 09:15:04 2013) [sssd[be[ipa.server-noc.com]]] [sasl_bind_send] (0x0020): ldap_sasl_bind failed (-5)[Timed out] (Tue Nov 26 09:15:04 2013) [sssd[be[ipa.server-noc.com]]] [sasl_bind_send] (0x0080): Extended failure message: [unknown error] (Tue Nov 26 09:15:04 2013) [sssd[be[ipa.server-noc.com]]] [fo_set_port_status] (0x0100): Marking port 0 of server 'tardis.ipa.server-noc.com' as 'not working' (Tue Nov 26 09:15:04 2013) [sssd[be[ipa.server-noc.com]]] [sdap_handle_release] (0x2000): Trace: sh[0x17dcf50], connected[1], ops[(nil)], ldap[0x17d6920], destructor_lock[0], release_memory[0] (Tue Nov 26 09:15:04 2013) [sssd[be[ipa.server-noc.com]]] [remove_connection_callback] (0x4000): Successfully removed connection callback. (Tue Nov 26 09:15:04 2013) [sssd[be[ipa.server-noc.com]]] [sdap_id_op_connect_done] (0x4000): notify error to op #1: 5 [Input/output error] (Tue Nov 26 09:15:04 2013) [sssd[be[ipa.server-noc.com]]] [acctinfo_callback] (0x0100): Request processed. Returned 3,5,User lookup failed (Tue Nov 26 09:15:04 2013) [sssd[be[ipa.server-noc.com]]] [sdap_id_release_conn_data] (0x4000): releasing unused connection (Tue Nov 26 09:15:04 2013) [sssd[be[ipa.server-noc.com]]] [sbus_dispatch] (0x4000): dbus conn: 174A470 (Tue Nov 26 09:15:04 2013) [sssd[be[ipa.server-noc.com]]] [sbus_dispatch] (0x4000): Dispatching. (Tue Nov 26 09:15:04 2013) [sssd[be[ipa.server-noc.com]]] [sbus_message_handler] (0x4000): Received SBUS method [getAccountInfo] (Tue Nov 26 09:15:04 2013) [sssd[be[ipa.server-noc.com]]] [be_get_account_info] (0x0100): Got request for [4097][1][name=nobody] (Tue Nov 26 09:15:04 2013) [sssd[be[ipa.server-noc.com]]] [sdap_id_op_connect_step] (0x4000): beginning to connect (Tue Nov 26 09:15:04 2013) [sssd[be[ipa.server-noc.com]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' (Tue Nov 26 09:15:04 2013) [sssd[be[ipa.server-noc.com]]] [get_server_status] (0x1000): Status of server 'tardis.ipa.server-noc.com' is 'working' (Tue Nov 26 09:15:04 2013) [sssd[be[ipa.server-noc.com]]] [get_port_status] (0x1000): Port status of port 0 for server 'tardis.ipa.server-noc.com' is 'not working' (Tue Nov 26 09:15:04 2013) [sssd[be[ipa.server-noc.com]]] [fo_resolve_service_send] (0x0020): No available servers for service 'IPA' (Tue Nov 26 09:15:04 2013) [sssd[be[ipa.server-noc.com]]] [be_resolve_server_done] (0x1000): Server resolution failed: 5 (Tue Nov 26 09:15:04 2013) [sssd[be[ipa.server-noc.com]]] [sdap_id_op_connect_done] (0x0020): Failed to connect, going offline (5 [Input/output error]) (Tue Nov 26 09:15:04 2013) [sssd[be[ipa.server-noc.com]]] [be_mark_offline] (0x2000): Going offline! (Tue Nov 26 09:15:04 2013) [sssd[be[ipa.server-noc.com]]] [be_run_offline_cb] (0x0080): Going offline. Running callbacks. (Tue Nov 26 09:15:04 2013) [sssd[be[ipa.server-noc.com]]] [sdap_id_op_connect_done] (0x4000): notify offline to op #1 (Tue Nov 26 09:15:04 2013) [sssd[be[ipa.server-noc.com]]] [acctinfo_callback] (0x0100): Request processed. Returned 1,11,Offline (Tue Nov 26 09:15:04 2013) [sssd[be[ipa.server-noc.com]]] [sdap_id_release_conn_data] (0x4000): releasing unused connection ... ... (Tue Nov 26 09:16:12 2013) [sssd[be[ipa.server-noc.com]]] [sbus_dispatch] (0x4000): dbus conn: 171FDB0 (Tue Nov 26 09:16:12 2013) [sssd[be[ipa.server-noc.com]]] [sbus_dispatch] (0x4000): Dispatching. (Tue Nov 26 09:16:12 2013) [sssd[be[ipa.server-noc.com]]] [sbus_message_handler] (0x4000): Received SBUS method [ping] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sbus_dispatch] (0x4000): dbus conn: 174A470 (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sbus_dispatch] (0x4000): Dispatching. (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sbus_message_handler] (0x4000): Received SBUS method [getAccountInfo] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [be_get_account_info] (0x0100): Got request for [4097][1][idnumber=493] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [be_get_account_info] (0x0100): Request processed. Returned 1,11,Fast reply - offline (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_id_op_connect_step] (0x4000): beginning to connect (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [get_server_status] (0x1000): Status of server 'tardis.ipa.server-noc.com' is 'working' (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [get_port_status] (0x1000): Port status of port 0 for server 'tardis.ipa.server-noc.com' is 'not working' (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [get_port_status] (0x0100): Reseting the status of port 0 for server 'tardis.ipa.server-noc.com' (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set to 10 seconds (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [get_server_status] (0x1000): Status of server 'tardis.ipa.server-noc.com' is 'working' (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [be_resolve_server_process] (0x1000): Saving the first resolved server (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [be_resolve_server_process] (0x0200): Found address for server tardis.ipa.server-noc.com: [203.147.190.30] TTL 7200 (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [ipa_resolve_callback] (0x0400): Constructed uri 'ldap://tardis.ipa.server-noc.com' (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sss_ldap_init_send] (0x4000): Using file descriptor [19] for LDAP connection. (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sss_ldap_init_send] (0x0400): Setting 10 seconds timeout for connecting (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_ldap_connect_callback_add] (0x1000): New LDAP connection to [ldap://tardis.ipa.server-noc.com:389/??base] with fd [19]. (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_rootdse_send] (0x4000): Getting rootdse (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(objectclass=*)][]. (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [*] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [altServer] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [namingContexts] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedControl] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedExtension] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedFeatures] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedLDAPVersion] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedSASLMechanisms] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [domainControllerFunctionality] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [defaultNamingContext] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [lastUSN] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [highestCommittedUSN] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 1 (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sbus_dispatch] (0x4000): dbus conn: 174A470 (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sbus_dispatch] (0x4000): Dispatching. (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sbus_message_handler] (0x4000): Received SBUS method [getAccountInfo] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [be_get_account_info] (0x0100): Got request for [4097][1][*] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_process_result] (0x2000): Trace: sh[0x171e770], connected[1], ops[0x17dded0], ldap[0x17378e0] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_parse_entry] (0x4000): OriginalDN: []. (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectClass] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [namingContexts] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [defaultnamingcontext] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [supportedExtension] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [supportedControl] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [supportedSASLMechanisms] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [supportedLDAPVersion] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [vendorName] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [vendorVersion] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [dataversion] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [netscapemdsuffix] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [lastusn] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_process_result] (0x2000): Trace: sh[0x171e770], connected[1], ops[0x17dded0], ldap[0x17378e0] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_rootdse_done] (0x2000): Got rootdse (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_rootdse_done] (0x2000): Skipping auto-detection of match rule (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_server_opts_from_rootdse] (0x4000): USN value: 7097911 (int: 7097911) (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_kinit_send] (0x0400): Attempting kinit (default, host/tardis.ipa.server-noc.com, SERVER-IPA, 86400) (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_kinit_next_kdc] (0x1000): Resolving next KDC for service IPA (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [get_server_status] (0x1000): Status of server 'tardis.ipa.server-noc.com' is 'working' (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set to 10 seconds (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [get_server_status] (0x1000): Status of server 'tardis.ipa.server-noc.com' is 'working' (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [be_resolve_server_process] (0x1000): Saving the first resolved server (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [be_resolve_server_process] (0x0200): Found address for server tardis.ipa.server-noc.com: [203.147.190.30] TTL 7200 (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_kinit_kdc_resolved] (0x1000): KDC resolved, attempting to get TGT... (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [create_tgt_req_send_buffer] (0x1000): buffer size: 56 (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [child_handler_setup] (0x2000): Setting up signal handler up for pid [26046] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [child_handler_setup] (0x2000): Signal handler set up for pid [26046] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [set_tgt_child_timeout] (0x0400): Setting 6 seconds timeout for tgt child (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_process_result] (0x2000): Trace: sh[0x171e770], connected[1], ops[(nil)], ldap[0x17378e0] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [write_pipe_handler] (0x0400): All data has been sent! (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sbus_dispatch] (0x4000): dbus conn: 174A470 (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sbus_dispatch] (0x4000): Dispatching. (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sbus_message_handler] (0x4000): Received SBUS method [getAccountInfo] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [be_get_account_info] (0x0100): Got request for [4098][1][*] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sbus_dispatch] (0x4000): dbus conn: 174A470 (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sbus_dispatch] (0x4000): Dispatching. (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sbus_message_handler] (0x4000): Received SBUS method [getAccountInfo] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [be_get_account_info] (0x0100): Got request for [4097][1][idnumber=493] (Tue Nov 26 09:16:21 2013) [sssd[be[ipa.server-noc.com]]] [sdap_id_op_connect_step] (0x4000): waiting for connection to complete (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sbus_dispatch] (0x4000): dbus conn: 171FDB0 (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sbus_dispatch] (0x4000): Dispatching. (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sbus_message_handler] (0x4000): Received SBUS method [ping] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [child_sig_handler] (0x1000): Waiting for child [26046]. (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [child_sig_handler] (0x0100): child [26046] finished successfully. (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sss_child_handler] (0x2000): waitpid failed [10]: No child processes (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [read_pipe_handler] (0x0400): EOF received, client finished (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_tgt_recv] (0x0400): Child responded: 0 [FILE:/var/lib/sss/db/ccache_SERVER-IPA], expired on [1385507781] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_cli_auth_step] (0x0100): expire timeout is 900 (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_cli_auth_step] (0x1000): the connection will expire at 1385422282 (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sasl_bind_send] (0x0100): Executing sasl bind mech: GSSAPI, user: host/tardis.ipa.server-noc.com (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [fo_set_port_status] (0x0100): Marking port 0 of server 'tardis.ipa.server-noc.com' as 'working' (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [set_server_common_status] (0x0100): Marking server 'tardis.ipa.server-noc.com' as 'working' (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_id_op_connect_done] (0x2000): Old USN: 7097881, New USN: 7097911 (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_id_op_connect_done] (0x4000): notify connected to op #1 (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_users_next_base] (0x0400): Searching for users with base [cn=accounts,dc=server-ipa] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(uidNumber=493)(objectclass=posixAccount))][cn=accounts,dc=server-ipa]. (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uid] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userPassword] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uidNumber] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gidNumber] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gecos] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [homeDirectory] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginShell] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [krbPrincipalName] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberOf] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [nsUniqueId] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [modifyTimestamp] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [entryUSN] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowLastChange] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowMin] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowMax] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowWarning] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowInactive] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowExpire] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowFlag] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [krbLastPwdChange] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [krbPasswordExpiration] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [pwdAttribute] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [authorizedService] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [accountExpires] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userAccountControl] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [nsAccountLock] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [host] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginDisabled] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginExpirationTime] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginAllowedTimeMap] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaSshPubKey] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 5 (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_id_op_connect_done] (0x4000): notify connected to op #2 (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_users_next_base] (0x0400): Searching for users with base [cn=accounts,dc=server-ipa] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(uidNumber=493)(objectclass=posixAccount))][cn=accounts,dc=server-ipa]. (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uid] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userPassword] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uidNumber] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gidNumber] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gecos] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [homeDirectory] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginShell] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [krbPrincipalName] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberOf] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [nsUniqueId] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [modifyTimestamp] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [entryUSN] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowLastChange] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowMin] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowMax] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowWarning] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowInactive] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowExpire] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowFlag] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [krbLastPwdChange] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [krbPasswordExpiration] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [pwdAttribute] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [authorizedService] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [accountExpires] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userAccountControl] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [nsAccountLock] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [host] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginDisabled] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginExpirationTime] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginAllowedTimeMap] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaSshPubKey] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 6 (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_id_op_connect_done] (0x4000): caching successful connection after 2 notifies (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [be_run_online_cb] (0x0080): Going online. Running callbacks. (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sbus_dispatch] (0x4000): dbus conn: 174A470 (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sbus_dispatch] (0x4000): Dispatching. (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sbus_message_handler] (0x4000): Received SBUS method [getAccountInfo] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [be_get_account_info] (0x0100): Got request for [4097][1][idnumber=495] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_users_next_base] (0x0400): Searching for users with base [cn=accounts,dc=server-ipa] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(uidNumber=495)(objectclass=posixAccount))][cn=accounts,dc=server-ipa]. (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uid] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userPassword] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uidNumber] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gidNumber] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gecos] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [homeDirectory] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginShell] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [krbPrincipalName] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberOf] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [nsUniqueId] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [modifyTimestamp] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [entryUSN] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowLastChange] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowMin] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowMax] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowWarning] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowInactive] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowExpire] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowFlag] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [krbLastPwdChange] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [krbPasswordExpiration] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [pwdAttribute] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [authorizedService] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [accountExpires] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userAccountControl] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [nsAccountLock] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [host] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginDisabled] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginExpirationTime] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginAllowedTimeMap] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaSshPubKey] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 7 (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [objectclass=ipaNTTrustedDomain][cn=trusts,dc=server-ipa]. (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaNTFlatName] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaNTTrustedDomainSID] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 8 (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [delayed_online_authentication_callback] (0x0200): Backend is online, starting delayed online authentication. also seeing these errors ... Tue Nov 26 09:42:02 2013) [sssd[be[ipa.server-noc.com]]] [ldb] (0x4000): start ldb transaction (nesting: 0) (Tue Nov 26 09:42:02 2013) [sssd[be[ipa.server-noc.com]]] [sysdb_update_ranges] (0x0400): Adding range [SERVER-IPA_id_range]. (Tue Nov 26 09:42:02 2013) [sssd[be[ipa.server-noc.com]]] [sysdb_range_create] (0x0040): Invalid range, expected that either the secondary base rid or the SID of the trusted domain is set, but not both or none of them. (Tue Nov 26 09:42:02 2013) [sssd[be[ipa.server-noc.com]]] [sysdb_range_create] (0x0400): Error: 22 (Invalid argument) (Tue Nov 26 09:42:02 2013) [sssd[be[ipa.server-noc.com]]] [sysdb_update_ranges] (0x0040): sysdb_range_create failed. (Tue Nov 26 09:42:02 2013) [sssd[be[ipa.server-noc.com]]] [ldb] (0x4000): cancel ldb transaction (nesting: 0) (Tue Nov 26 09:42:02 2013) [sssd[be[ipa.server-noc.com]]] [ipa_subdomains_handler_ranges_done] (0x0040): sysdb_update_ranges failed. Have not setup any AD trusts etc ... rgds Matt B. On 11/25/2013 06:49 PM, Sumit Bose wrote: > On Mon, Nov 25, 2013 at 09:23:22AM +1000, Matt Bryant wrote: >> All, >> >> Was wondering if anyone can help out or point us the in right >> direction. Ever since we updated from IPA v2.1 to IPA v3.0 have been >> seeing some intermittent errors when trying to change passwords etc. >> Getting the error cannot change password since system offline. >> >> Have increased the logging and found that quite frequently the >> sasl_bind using the host principle is timing out and failing ... >> (whether this is red herring or not dont know but cant be good >> anyhow) >> >> (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] >> [sdap_kinit_send] (0x0400): Attempting kinit (default, >> host/tardis.ipa.server-noc.com, SERVER-IPA, 86400) >> (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] >> [sdap_kinit_next_kdc] (0x1000): Resolving next KDC for service IPA >> (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] >> [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' >> (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] >> [get_server_status] (0x1000): Status of server >> 'tardis.ipa.server-noc.com' is 'working' >> (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] >> [fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set >> to 10 seconds >> (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] >> [get_server_status] (0x1000): Status of server >> 'tardis.ipa.server-noc.com' is 'working' >> (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] >> [be_resolve_server_process] (0x1000): Saving the first resolved >> server >> (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] >> [be_resolve_server_process] (0x0200): Found address for server >> tardis.ipa.server-noc.com: [203.147.190.30] TTL 7200 >> (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] >> [sdap_kinit_kdc_resolved] (0x1000): KDC resolved, attempting to get >> TGT... >> (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] >> [create_tgt_req_send_buffer] (0x1000): buffer size: 56 >> (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] >> [child_handler_setup] (0x2000): Setting up signal handler up for pid >> [3734] >> (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] >> [child_handler_setup] (0x2000): Signal handler set up for pid [3734] >> (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] >> [set_tgt_child_timeout] (0x0400): Setting 6 seconds timeout for tgt >> child >> (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] >> [sdap_process_result] (0x2000): Trace: sh[0xa45960], connected[1], >> ops[(nil)], ldap[0xa12200] >> (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] >> [sdap_process_result] (0x2000): Trace: ldap_result found nothing! >> (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] >> [write_pipe_handler] (0x0400): All data has been sent! >> (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] >> [child_sig_handler] (0x1000): Waiting for child [3734]. >> (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] >> [child_sig_handler] (0x0100): child [3734] finished successfully. >> (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] >> [sss_child_handler] (0x2000): waitpid failed [10]: No child >> processes >> (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] >> [read_pipe_handler] (0x0400): EOF received, client finished >> (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] >> [sdap_get_tgt_recv] (0x0400): Child responded: 0 >> [FILE:/var/lib/sss/db/ccache_SERVER-IPA], expired on [1385420045] >> (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] >> [sdap_cli_auth_step] (0x0100): expire timeout is 900 >> (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] >> [sdap_cli_auth_step] (0x1000): the connection will expire at >> 1385334545 >> (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] >> [sasl_bind_send] (0x0100): Executing sasl bind mech: GSSAPI, user: >> host/tardis.ipa.server-noc.com >> (Mon Nov 25 08:54:11 2013) [sssd[be[ipa.server-noc.com]]] >> [sasl_bind_send] (0x0020): ldap_sasl_bind failed (-5)[Timed out] >> (Mon Nov 25 08:54:11 2013) [sssd[be[ipa.server-noc.com]]] >> [sasl_bind_send] (0x0080): Extended failure message: [unknown error] >> (Mon Nov 25 08:54:11 2013) [sssd[be[ipa.server-noc.com]]] >> [fo_set_port_status] (0x0100): Marking port 0 of server >> 'tardis.ipa.server-noc.com' as 'not working' >> (Mon Nov 25 08:54:11 2013) [sssd[be[ipa.server-noc.com]]] >> [sdap_handle_release] (0x2000): Trace: sh[0xa45960], connected[1], >> ops[(nil)], ldap[0xa12200], destructor_lock[0], release_memory[0] >> .. >> .. >> >> it then goes on to connect to fail over server and succeed and >> shortly after the master server is tested and marked as working >> again ... works for a couple of times then time out again .. any >> pointers gratefully received. > According to the logs I would say that this timeout happens on the > LDAP server side. Do you have a chance to check the server logs to see > what happens at this time on the server? > > You can increase the timeout value on the client by setting > ldap_opt_timeout to a larger value then 6 (the default). But please note > that the operation might take longer then letting SSSD fail over to the > next server. > > HTH > > bye, > Sumit > >> >> packages used ... >> >> ipa-server-3.0.0-25.el6.x86_64 >> sssd-1.9.2-82.11.el6_4.x86_64 >> >> rgds >> >> Matt Bryant >> >> _______________________________________________ >> 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 _______________________________________________ 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 Tue Nov 26 08:41:28 2013 From: sbose at redhat.com (Sumit Bose) Date: Tue, 26 Nov 2013 09:41:28 +0100 Subject: [Freeipa-users] Intermittent Issues changing passwords since updating to ipa v3 and sasl_bind timeouts .. In-Reply-To: <52942C92.1040003@melbourneit.com.au> References: <5293FF79.5@melbourneit.com.au> <52942C92.1040003@melbourneit.com.au> Message-ID: <20131126084128.GK3414@localhost.localdomain> On Tue, Nov 26, 2013 at 03:07:30PM +1000, Matt Bryant wrote: > OK so been running some tcpdumps on this issue and the wierd thing is .. > > can see the initial sasl bind request followed by ack from ldap ... > then nothing ldap/gssapi related until the unbind request post the > 6s timeout period ... > > so no friggin idea whats going on just a big resounding nothing ... > > 14:20:47.065606 IP tardis.ipa.server-noc.com.40953 > > tardis.ipa.server-noc.com.ldap: Flags [P.], seq 261:974, ack 1502, > win 280, options [nop,nop,TS val 23677005 ecr 23676785], length 713 > 14:20:47.104816 IP tardis.ipa.server-noc.com.ldap > > tardis.ipa.server-noc.com.40953: Flags [.], ack 974, win 276, > options [nop,nop,TS val 23677045 ecr 23677005], length 0 > 14:20:53.066009 IP tardis.ipa.server-noc.com.40953 > > tardis.ipa.server-noc.com.ldap: Flags [P.], seq 974:981, ack 1502, > win 280, options [nop,nop,TS val 23683006 ecr 23677045], length 7 > 14:20:53.066021 IP tardis.ipa.server-noc.com.ldap > > tardis.ipa.server-noc.com.40953: Flags [.], ack 981, win 276, > options [nop,nop,TS val 23683006 ecr 23683006], length 0 > 14:20:53.066100 IP tardis.ipa.server-noc.com.40953 > > tardis.ipa.server-noc.com.ldap: Flags [F.], seq 981, ack 1502, win > 280, options [nop,nop,TS val 23683006 ecr 23683006], length 0 > 14:20:53.105731 IP tardis.ipa.server-noc.com.ldap > > tardis.ipa.server-noc.com.40953: Flags [.], ack 982, win 276, > options [nop,nop,TS val 23683046 ecr 23683006], length 0 > 14:20:53.111470 IP tardis.ipa.server-noc.com.ldap > > tardis.ipa.server-noc.com.40953: Flags [F.], seq 1502, ack 982, win > 276, options [nop,nop,TS val 23683051 ecr 23683006], length 0 > 14:20:53.111486 IP tardis.ipa.server-noc.com.40953 > > tardis.ipa.server-noc.com.ldap: Flags [.], ack 1503, win 280, > options [nop,nop,TS val 23683051 ecr 23683051], length 0 > > Comparing that to a connection that works and brings the backend online .. > > 14:22:01.193809 IP tardis.ipa.server-noc.com.41031 > > tardis.ipa.server-noc.com.ldap: Flags [S], seq 3387425755, win > 32792, options [mss 16396,sackOK,TS val 23751134 ecr 0,nop,wscale > 7], length 0 > 14:22:01.193833 IP tardis.ipa.server-noc.com.ldap > > tardis.ipa.server-noc.com.41031: Flags [S.], seq 1024653772, ack > 3387425756, win 32768, options [mss 16396,sackOK,TS val 23751134 ecr > 23751134,nop,wscale 7], length 0 > 14:22:01.193848 IP tardis.ipa.server-noc.com.41031 > > tardis.ipa.server-noc.com.ldap: Flags [.], ack 1, win 257, options > [nop,nop,TS val 23751134 ecr 23751134], length 0 > 14:22:01.194371 IP tardis.ipa.server-noc.com.41031 > > tardis.ipa.server-noc.com.ldap: Flags [P.], seq 1:261, ack 1, win > 257, options [nop,nop,TS val 23751134 ecr 23751134], length 260 > 14:22:01.194385 IP tardis.ipa.server-noc.com.ldap > > tardis.ipa.server-noc.com.41031: Flags [.], ack 261, win 265, > options [nop,nop,TS val 23751134 ecr 23751134], length 0 > 14:22:01.195187 IP tardis.ipa.server-noc.com.ldap > > tardis.ipa.server-noc.com.41031: Flags [P.], seq 1:1502, ack 261, > win 265, options [nop,nop,TS val 23751135 ecr 23751134], length 1501 > 14:22:01.195201 IP tardis.ipa.server-noc.com.41031 > > tardis.ipa.server-noc.com.ldap: Flags [.], ack 1502, win 280, > options [nop,nop,TS val 23751135 ecr 23751135], length 0 > 14:22:01.443288 IP tardis.ipa.server-noc.com.41031 > > tardis.ipa.server-noc.com.ldap: Flags [P.], seq 261:953, ack 1502, > win 280, options [nop,nop,TS val 23751383 ecr 23751135], length 692 > 14:22:01.470047 IP tardis.ipa.server-noc.com.ldap > > tardis.ipa.server-noc.com.41031: Flags [P.], seq 1502:1677, ack 953, > win 276, options [nop,nop,TS val 23751410 ecr 23751383], length 175 > 14:22:01.470062 IP tardis.ipa.server-noc.com.41031 > > tardis.ipa.server-noc.com.ldap: Flags [.], ack 1677, win 304, > options [nop,nop,TS val 23751410 ecr 23751410], length 0 > 14:22:01.470469 IP tardis.ipa.server-noc.com.41031 > > tardis.ipa.server-noc.com.ldap: Flags [P.], seq 953:975, ack 1677, > win 304, options [nop,nop,TS val 23751410 ecr 23751410], length 22 > 14:22:01.471249 IP tardis.ipa.server-noc.com.ldap > > tardis.ipa.server-noc.com.41031: Flags [P.], seq 1677:1725, ack 975, > win 276, options [nop,nop,TS val 23751411 ecr 23751410], length 48 > 14:22:01.471298 IP tardis.ipa.server-noc.com.41031 > > tardis.ipa.server-noc.com.ldap: Flags [P.], seq 975:1031, ack 1725, > win 304, options [nop,nop,TS val 23751411 ecr 23751411], length 56 > 14:22:01.484334 IP tardis.ipa.server-noc.com.ldap > > tardis.ipa.server-noc.com.41031: Flags [P.], seq 1725:1739, ack > 1031, win 276, options [nop,nop,TS val 23751424 ecr 23751411], > length 14 > 14:22:01.485505 IP tardis.ipa.server-noc.com.41031 > > tardis.ipa.server-noc.com.ldap: Flags [P.], seq 1031:1656, ack 1739, > win 304, options [nop,nop,TS val 23751425 ecr 23751424], length 625 > 14:22:01.486736 IP tardis.ipa.server-noc.com.41031 > > tardis.ipa.server-noc.com.ldap: Flags [P.], seq 1656:2284, ack 1739, > win 304, options [nop,nop,TS val 23751427 ecr 23751424], length 628 > 14:22:01.486747 IP tardis.ipa.server-noc.com.ldap > > tardis.ipa.server-noc.com.41031: Flags [.], ack 2284, win 297, > options [nop,nop,TS val 23751427 ecr 23751425], length 0 > 14:22:01.516185 IP tardis.ipa.server-noc.com.41031 > > tardis.ipa.server-noc.com.ldap: Flags [P.], seq 2284:2474, ack 1739, > win 304, options [nop,nop,TS val 23751456 ecr 23751427], length 190 > 14:22:01.555664 IP tardis.ipa.server-noc.com.ldap > > tardis.ipa.server-noc.com.41031: Flags [.], ack 2474, win 308, > options [nop,nop,TS val 23751496 ecr 23751456], length 0 > 14:22:07.487451 IP tardis.ipa.server-noc.com.41031 > > tardis.ipa.server-noc.com.ldap: Flags [P.], seq 2474:2546, ack 1739, > win 304, options [nop,nop,TS val 23757427 ecr 23751496], length 72 > 14:22:07.487467 IP tardis.ipa.server-noc.com.ldap > > tardis.ipa.server-noc.com.41031: Flags [.], ack 2546, win 308, > options [nop,nop,TS val 23757427 ecr 23757427], length 0 > 14:22:07.487983 IP tardis.ipa.server-noc.com.41031 > > tardis.ipa.server-noc.com.ldap: Flags [P.], seq 2546:2618, ack 1739, > win 304, options [nop,nop,TS val 23757428 ecr 23757427], length 72 > 14:22:07.487994 IP tardis.ipa.server-noc.com.ldap > > tardis.ipa.server-noc.com.41031: Flags [.], ack 2618, win 308, > options [nop,nop,TS val 23757428 ecr 23757428], length 0 > 14:22:07.516863 IP tardis.ipa.server-noc.com.41031 > > tardis.ipa.server-noc.com.ldap: Flags [P.], seq 2618:2690, ack 1739, > win 304, options [nop,nop,TS val 23757457 ecr 23757428], length 72 > 14:22:07.516883 IP tardis.ipa.server-noc.com.ldap > > tardis.ipa.server-noc.com.41031: Flags [.], ack 2690, win 308, > options [nop,nop,TS val 23757457 ecr 23757457], length 0 > 14:22:07.517102 IP tardis.ipa.server-noc.com.41031 > > tardis.ipa.server-noc.com.ldap: Flags [P.], seq 2690:2761, ack 1739, > win 304, options [nop,nop,TS val 23757457 ecr 23757457], length 71 > 14:22:07.517116 IP tardis.ipa.server-noc.com.ldap > > tardis.ipa.server-noc.com.41031: Flags [.], ack 2761, win 308, > options [nop,nop,TS val 23757457 ecr 23757457], length 0 > 14:22:07.517573 IP tardis.ipa.server-noc.com.41031 > > tardis.ipa.server-noc.com.ldap: Flags [F.], seq 2761, ack 1739, win > 304, options [nop,nop,TS val 23757457 ecr 23757457], length 0 > 14:22:07.556841 IP tardis.ipa.server-noc.com.ldap > > tardis.ipa.server-noc.com.41031: Flags [.], ack 2762, win 308, > options [nop,nop,TS val 23757497 ecr 23757457], length 0 > 14:22:13.497311 IP tardis.ipa.server-noc.com.ldap > > tardis.ipa.server-noc.com.41031: Flags [P.], seq 1739:1817, ack > 2762, win 308, options [nop,nop,TS val 23763437 ecr 23757457], > length 78 > 14:22:13.497333 IP tardis.ipa.server-noc.com.41031 > > tardis.ipa.server-noc.com.ldap: Flags [R], seq 3387428517, win 0, > length 0 > 14:22:13.526895 IP tardis.ipa.server-noc.com.ldap > > tardis.ipa.server-noc.com.41031: Flags [R.], seq 1817, ack 2762, win > 308, options [nop,nop,TS val 23763467 ecr 23757457], length 0 > > which using the ol' wireshark relate to > > bind request with a bind response traversing back and fro from ldap > server till a bind success from ldap server and the query/queries > run .. so to me it seems that there are times (and quite a few of > them) where a bind request gets no response back from the server ... > > Has anyone seen this ... no, I have not seen this. Some general comments about the SSSD log files. The ldap_child only handles the part of getting a Kerberos ticket. The complete bind happens inside the OpenLDAP ldap_sasl_bind() call where we currently do not get any debug output from. Can you try if you see the same delay with the ldapsearch command line utility? You can use the same credentials as SSSD if you call e.g: KRB5CCNAME=FILE:/var/lib/sss/db/ccache_YOUR.DOMAIN ldapsearch -Y GSSAPI \ -H ldap://your.ipa.server -b 'dc=ipa,dc=domain' uid=admin If it can be reproduced with ldapsearch you can use the option '-d -1' to get full debug output. I wonder if your server is a busy on handling lots of encrypted connections? In this case, depending on how the session keys for those connections are generated, the entropy pool might be too small to generate a sufficient amount of random data for the keys which would lead to a timeout in the application until enough entropy is gathered. But I have to admit that I do not know which source of random data 389ds is using. bye, Sumit > > rgds > > Matt B. > From emil at melt.se Tue Nov 26 09:16:01 2013 From: emil at melt.se (Emil Petersson) Date: Tue, 26 Nov 2013 10:16:01 +0100 Subject: [Freeipa-users] IPA winsync replication In-Reply-To: <5293E5B3.4020106@redhat.com> References: <5293694E.9060606@melt.se> <529378EF.3040907@redhat.com> <5293E3F1.3010002@redhat.com> <5293E5B3.4020106@redhat.com> Message-ID: <529466D1.7020207@melt.se> On 26/11/13 01:05, Rich Megginson wrote: > On 11/25/2013 04:57 PM, Rich Megginson wrote: >> On 11/25/2013 11:51 AM, Emil Petersson wrote: >>> On 25 Nov 2013, at 17:21, Rich Megginson >> > wrote: >>> >>>> On 11/25/2013 08:14 AM, Emil Petersson wrote: >>>>> Hi, >>>>> >>>>> I'm running FreeIPA 3.0 under RHEL6.4. I'm seeing some unexpected >>>>> behaviour with winsync replication. >>>>> >>>>> 1. I have a working winsync agreement, and users are synced correctly. >>>>> >>>>> 2. If a user already exists in in IPA when I sync it from AD, I'm >>>>> seeing the following in the dirsrv error logs: >>>>> >>>>> [25/Nov/2013:14:29:03 +0000] NSMMReplicationPlugin - >>>>> windows_update_local_entry: failed to modify entry >>>>> uid=username,cn=users,cn=accounts,dc=domain,dc=net - error >>>>> 21:Invalid syntax >>>>> >>>>> I assume this is because the user already exists in dirsrv? Fine. >>>> >>>> No. Error 21 is Invalid Syntax. This means the format of the data >>>> in the attribute in AD is not correct for the given syntax. For >>>> example, if the syntax is Integer, this means the data should be a >>>> valid integer. However, AD allows data that violates LDAP syntax. >>>> >>>> Can you post the data from the AD entry that corresponds to >>>> uid=username,cn=users,cn=accounts,dc=domain,dc=net? Please be sure >>>> to obscure any sensitive data. I'd like to identify the data that >>>> is causing this problem. >>> >>> Certainly, here goes: >>> >>> dn: CN=Firstname >>> Lastname,OU=LDAP,OU=Domain,OU=Users,OU=Domain,OU=Organization,DC= >>> domain,DC=com >>> objectClass: top >>> objectClass: person >>> objectClass: organizationalPerson >>> objectClass: user >>> cn: Firstname Lastname >>> sn: Lastname >>> title: Sysadmin >>> description: Employee >>> physicalDeliveryOfficeName: XX-XX-XX >>> telephoneNumber: +00 00 000 0 >>> facsimileTelephoneNumber: +00 00 000 0 >>> givenName: Firstname >>> distinguishedName: CN=Firstname >>> Lastname,OU=LDAP,OU=Domain,OU=Users,OU=Domain,OU=O >>> rganization,DC=domain,DC=com >>> instanceType: 4 >>> whenCreated: 20110321122858.0Z >>> whenChanged: 20131120104224.0Z >>> displayName: Firstname Lastname >>> uSNCreated: 76590 >>> ngame,DC=com >>> memberOf: CN=All,OU=OrgGroups,OU=Organization,DC=domain,DC=com >>> memberOf: CN=sysadmins,OU=OrgGroups,OU=Organization,DC=domain,DC=com >>> uSNChanged: 66378160 >>> department: Infrastructure >>> company: Company name >>> homeMTA: CN=Microsoft MTA,CN=MBX,CN=Servers,CN=Exchange >>> Administrative Group ( >>> FYDIBOHF23SPDLT),CN=Administrative >>> Groups,CN=globalmail,CN=Microsoft Exchange >>> ,CN=Services,CN=Configuration,DC=domain,DC=com >>> proxyAddresses: SMTP:first.last at domain.com >>> proxyAddresses: smtp:first.last at domain2.com >>> proxyAddresses: smtp:first.last at domain3.com >>> proxyAddresses: sip:first.last at domain.com >>> proxyAddresses: X400:C=SE;A= >>> ;P=globalmail;O=Exchange;S=Lastname;G=Firstname; >>> homeMDB: CN=DB3,CN=SG03 - >>> 2GB,CN=InformationStore,CN=MBX,CN=Servers,CN=Exchang >>> e Administrative Group (FYDIBOHF23SPDLT),CN=Administrative >>> Groups,CN=globalma >>> il,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain,DC=com >>> garbageCollPeriod: 1209600 >>> mDBUseDefaults: TRUE >>> extensionAttribute8: Companyname >>> mailNickname: username >>> protocolSettings:: SFRUUMKnMcKnMcKnwqfCp8KnwqfCpw== >>> protocolSettings:: T1dBwqcx >>> internetEncoding: 0 >>> name: Firstnam Lastname >>> objectGUID:: pDdL7yY7gEuqRdQLTjLo0w== >>> userAccountControl: 512 >>> badPwdCount: 0 >>> codePage: 0 >>> countryCode: 0 >>> homeDirectory: \\path\to\home >>> homeDrive: H: >>> badPasswordTime: 130295283826410995 >>> lastLogoff: 0 >>> lastLogon: 130297464093469882 >>> pwdLastSet: 130294130189116476 >>> primaryGroupID: 513 >>> objectSid:: AQUAAAoiadjfojdfojsodijfQkAH5TsrAA== >>> accountExpires: 0 >>> logonCount: 6909 >>> sAMAccountName: username >>> sAMAccountType: 805306368 >>> showInAddressBook: CN=Default Global Address List,CN=All Global >>> Address Lists, >>> CN=Address Lists Container,CN=globalmail,CN=Microsoft >>> Exchange,CN=Services,CN >>> =Configuration,DC=domain,DC=com >>> showInAddressBook: CN=All Users,CN=All Address Lists,CN=Address >>> Lists Containe >>> r,CN=globalmail,CN=Microsoft >>> Exchange,CN=Services,CN=Configuration,DC=domain, >>> DC=com >>> legacyExchangeDN: /o=globalmail/ou=Exchange Administrative Group >>> (FYDIBOHF23SP >>> DLT)/cn=Recipients/cn=username >>> userPrincipalName: first at domain.com >>> lockoutTime: 0 >>> ipPhone: +00 00 00 00 >>> objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=domain,DC=com >>> dSCorePropagationData: 20131118102944.0Z >>> dSCorePropagationData: 20131118102934.0Z >>> dSCorePropagationData: 20130313150036.0Z >>> dSCorePropagationData: 20120821144903.0Z >>> dSCorePropagationData: 16010101181216.0Z >>> lastLogonTimestamp: 130294177442871790 >>> textEncodedORAddress: c=XX;a= >>> ;p=globalmail;o=Exchange;s=Lastname;g=Firstname; >>> mail: first.last at domain.com >>> manager: CN=Manager >>> Name,OU=Domain,OU=Users,OU=Domain,OU=Organization,DC=o >>> ngame,DC=com >>> mobile:: KzQ2NzI3mjMEMTEwwqAJ > > I think this may be the problem. mobile contains non printable > characters: > $ python > >>> import base64 > >>> base64.b64decode('KzQ2NzI3mjMEMTEwwqAJ') > '+46727\x9a3\x04110\xc2\xa0\t' > > Looks like the mobile phone number contains utf8 characters. It must not: > /* Per RFC4517: > * > * TelephoneNumber = PrintableString > * PrintableString = 1*PrintableCharacter > */ > > Unfortunately, AD syntax checking leaves a lot to be desired, so it > allows this and other bogus data. IPA/389 is much stricter. Hey Rich, You are correct! All "mobile" entries in our AD is base64 encoded and ends with "\xc2\xa0\t". Removing the junk characters from the mobile entry makes the user sync correctly, regardless of if the user pre exists or not. Issue solved, thanks alot for pointing this out! -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew at andrewklau.com Tue Nov 26 13:42:17 2013 From: andrew at andrewklau.com (Andrew Lau) Date: Wed, 27 Nov 2013 00:42:17 +1100 Subject: [Freeipa-users] Failed to remove host (Some entries were not deleted) Message-ID: Hi, I've got an issue where I can't seem to remove a host from my freeipa install. It gives me an error: Certificate operation cannot be completed: EXCEPTION (Certificate serial number 0xfff0006 not found) I thought it might be a replica issue, so I forced sync and also tried re-initializing the replica but no luck. Any suggestions? Thanks, Andrew -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Tue Nov 26 13:58:03 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 26 Nov 2013 08:58:03 -0500 Subject: [Freeipa-users] Failed to remove host (Some entries were not deleted) In-Reply-To: References: Message-ID: <5294A8EB.1080101@redhat.com> Andrew Lau wrote: > Hi, > > I've got an issue where I can't seem to remove a host from my freeipa > install. It gives me an error: > > Certificate operation cannot be completed: EXCEPTION (Certificate serial > number 0xfff0006 not found) > > I thought it might be a replica issue, so I forced sync and also tried > re-initializing the replica but no luck. > > Any suggestions? Deleting a host does a number of additional things: - revokes the certificate for the host if it exists - deletes the services for that host, revoking their certificates as needed So in this case the host has a certificate associated with it and revocation is failing because the CA doesn't have a record of this certificate. If you can be sure that the certificate is not in the IPA CA you can clear the value with: # ipa host-mod --certificate= test.example.com This passes an empty value to --certificate which results in removing the value. Then you should be able to delete the host. rob From andrew at andrewklau.com Tue Nov 26 14:17:23 2013 From: andrew at andrewklau.com (Andrew Lau) Date: Wed, 27 Nov 2013 01:17:23 +1100 Subject: [Freeipa-users] Failed to remove host (Some entries were not deleted) In-Reply-To: <5294A8EB.1080101@redhat.com> References: <5294A8EB.1080101@redhat.com> Message-ID: On Wed, Nov 27, 2013 at 12:58 AM, Rob Crittenden wrote: > Andrew Lau wrote: > >> Hi, >> >> I've got an issue where I can't seem to remove a host from my freeipa >> install. It gives me an error: >> >> Certificate operation cannot be completed: EXCEPTION (Certificate serial >> number 0xfff0006 not found) >> >> I thought it might be a replica issue, so I forced sync and also tried >> re-initializing the replica but no luck. >> >> Any suggestions? >> > > Deleting a host does a number of additional things: > - revokes the certificate for the host if it exists > - deletes the services for that host, revoking their certificates as > needed > > So in this case the host has a certificate associated with it and > revocation is failing because the CA doesn't have a record of this > certificate. > > If you can be sure that the certificate is not in the IPA CA you can clear > the value with: > > # ipa host-mod --certificate= test.example.com > > This passes an empty value to --certificate which results in removing the > value. Then you should be able to delete the host. > > rob > > Thanks that worked. Andrew. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Tue Nov 26 18:52:42 2013 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 26 Nov 2013 13:52:42 -0500 Subject: [Freeipa-users] [SOLVED] Re: IPA winsync replication In-Reply-To: <529466D1.7020207@melt.se> References: <5293694E.9060606@melt.se> <529378EF.3040907@redhat.com> <5293E3F1.3010002@redhat.com> <5293E5B3.4020106@redhat.com> <529466D1.7020207@melt.se> Message-ID: <5294EDFA.4060100@redhat.com> On 11/26/2013 04:16 AM, Emil Petersson wrote: > > On 26/11/13 01:05, Rich Megginson wrote: >> On 11/25/2013 04:57 PM, Rich Megginson wrote: >>> On 11/25/2013 11:51 AM, Emil Petersson wrote: >>>> On 25 Nov 2013, at 17:21, Rich Megginson >>> > wrote: >>>> >>>>> On 11/25/2013 08:14 AM, Emil Petersson wrote: >>>>>> Hi, >>>>>> >>>>>> I'm running FreeIPA 3.0 under RHEL6.4. I'm seeing some unexpected >>>>>> behaviour with winsync replication. >>>>>> >>>>>> 1. I have a working winsync agreement, and users are synced >>>>>> correctly. >>>>>> >>>>>> 2. If a user already exists in in IPA when I sync it from AD, I'm >>>>>> seeing the following in the dirsrv error logs: >>>>>> >>>>>> [25/Nov/2013:14:29:03 +0000] NSMMReplicationPlugin - >>>>>> windows_update_local_entry: failed to modify entry >>>>>> uid=username,cn=users,cn=accounts,dc=domain,dc=net - error >>>>>> 21:Invalid syntax >>>>>> >>>>>> I assume this is because the user already exists in dirsrv? Fine. >>>>> >>>>> No. Error 21 is Invalid Syntax. This means the format of the >>>>> data in the attribute in AD is not correct for the given syntax. >>>>> For example, if the syntax is Integer, this means the data should >>>>> be a valid integer. However, AD allows data that violates LDAP >>>>> syntax. >>>>> >>>>> Can you post the data from the AD entry that corresponds to >>>>> uid=username,cn=users,cn=accounts,dc=domain,dc=net? Please be >>>>> sure to obscure any sensitive data. I'd like to identify the data >>>>> that is causing this problem. >>>> >>>> Certainly, here goes: >>>> >>>> dn: CN=Firstname >>>> Lastname,OU=LDAP,OU=Domain,OU=Users,OU=Domain,OU=Organization,DC= >>>> domain,DC=com >>>> objectClass: top >>>> objectClass: person >>>> objectClass: organizationalPerson >>>> objectClass: user >>>> cn: Firstname Lastname >>>> sn: Lastname >>>> title: Sysadmin >>>> description: Employee >>>> physicalDeliveryOfficeName: XX-XX-XX >>>> telephoneNumber: +00 00 000 0 >>>> facsimileTelephoneNumber: +00 00 000 0 >>>> givenName: Firstname >>>> distinguishedName: CN=Firstname >>>> Lastname,OU=LDAP,OU=Domain,OU=Users,OU=Domain,OU=O >>>> rganization,DC=domain,DC=com >>>> instanceType: 4 >>>> whenCreated: 20110321122858.0Z >>>> whenChanged: 20131120104224.0Z >>>> displayName: Firstname Lastname >>>> uSNCreated: 76590 >>>> ngame,DC=com >>>> memberOf: CN=All,OU=OrgGroups,OU=Organization,DC=domain,DC=com >>>> memberOf: CN=sysadmins,OU=OrgGroups,OU=Organization,DC=domain,DC=com >>>> uSNChanged: 66378160 >>>> department: Infrastructure >>>> company: Company name >>>> homeMTA: CN=Microsoft MTA,CN=MBX,CN=Servers,CN=Exchange >>>> Administrative Group ( >>>> FYDIBOHF23SPDLT),CN=Administrative >>>> Groups,CN=globalmail,CN=Microsoft Exchange >>>> ,CN=Services,CN=Configuration,DC=domain,DC=com >>>> proxyAddresses: SMTP:first.last at domain.com >>>> proxyAddresses: smtp:first.last at domain2.com >>>> proxyAddresses: smtp:first.last at domain3.com >>>> proxyAddresses: sip:first.last at domain.com >>>> proxyAddresses: X400:C=SE;A= >>>> ;P=globalmail;O=Exchange;S=Lastname;G=Firstname; >>>> homeMDB: CN=DB3,CN=SG03 - >>>> 2GB,CN=InformationStore,CN=MBX,CN=Servers,CN=Exchang >>>> e Administrative Group (FYDIBOHF23SPDLT),CN=Administrative >>>> Groups,CN=globalma >>>> il,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain,DC=com >>>> garbageCollPeriod: 1209600 >>>> mDBUseDefaults: TRUE >>>> extensionAttribute8: Companyname >>>> mailNickname: username >>>> protocolSettings:: SFRUUMKnMcKnMcKnwqfCp8KnwqfCpw== >>>> protocolSettings:: T1dBwqcx >>>> internetEncoding: 0 >>>> name: Firstnam Lastname >>>> objectGUID:: pDdL7yY7gEuqRdQLTjLo0w== >>>> userAccountControl: 512 >>>> badPwdCount: 0 >>>> codePage: 0 >>>> countryCode: 0 >>>> homeDirectory: \\path\to\home >>>> homeDrive: H: >>>> badPasswordTime: 130295283826410995 >>>> lastLogoff: 0 >>>> lastLogon: 130297464093469882 >>>> pwdLastSet: 130294130189116476 >>>> primaryGroupID: 513 >>>> objectSid:: AQUAAAoiadjfojdfojsodijfQkAH5TsrAA== >>>> accountExpires: 0 >>>> logonCount: 6909 >>>> sAMAccountName: username >>>> sAMAccountType: 805306368 >>>> showInAddressBook: CN=Default Global Address List,CN=All Global >>>> Address Lists, >>>> CN=Address Lists Container,CN=globalmail,CN=Microsoft >>>> Exchange,CN=Services,CN >>>> =Configuration,DC=domain,DC=com >>>> showInAddressBook: CN=All Users,CN=All Address Lists,CN=Address >>>> Lists Containe >>>> r,CN=globalmail,CN=Microsoft >>>> Exchange,CN=Services,CN=Configuration,DC=domain, >>>> DC=com >>>> legacyExchangeDN: /o=globalmail/ou=Exchange Administrative Group >>>> (FYDIBOHF23SP >>>> DLT)/cn=Recipients/cn=username >>>> userPrincipalName: first at domain.com >>>> lockoutTime: 0 >>>> ipPhone: +00 00 00 00 >>>> objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=domain,DC=com >>>> dSCorePropagationData: 20131118102944.0Z >>>> dSCorePropagationData: 20131118102934.0Z >>>> dSCorePropagationData: 20130313150036.0Z >>>> dSCorePropagationData: 20120821144903.0Z >>>> dSCorePropagationData: 16010101181216.0Z >>>> lastLogonTimestamp: 130294177442871790 >>>> textEncodedORAddress: c=XX;a= >>>> ;p=globalmail;o=Exchange;s=Lastname;g=Firstname; >>>> mail: first.last at domain.com >>>> manager: CN=Manager >>>> Name,OU=Domain,OU=Users,OU=Domain,OU=Organization,DC=o >>>> ngame,DC=com >>>> mobile:: KzQ2NzI3mjMEMTEwwqAJ >> >> I think this may be the problem. mobile contains non printable >> characters: >> $ python >> >>> import base64 >> >>> base64.b64decode('KzQ2NzI3mjMEMTEwwqAJ') >> '+46727\x9a3\x04110\xc2\xa0\t' >> >> Looks like the mobile phone number contains utf8 characters. It must >> not: >> /* Per RFC4517: >> * >> * TelephoneNumber = PrintableString >> * PrintableString = 1*PrintableCharacter >> */ >> >> Unfortunately, AD syntax checking leaves a lot to be desired, so it >> allows this and other bogus data. IPA/389 is much stricter. > Hey Rich, > > You are correct! > > All "mobile" entries in our AD is base64 encoded and ends with > "\xc2\xa0\t". Removing the junk characters from the mobile entry makes > the user sync correctly, regardless of if the user pre exists or not. > Issue solved, thanks alot for pointing this out! > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users Added a solved tag to subj. -- 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 Tue Nov 26 18:54:44 2013 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 26 Nov 2013 13:54:44 -0500 Subject: [Freeipa-users] [SOLVED] Re: Failed to remove host (Some entries were not deleted) In-Reply-To: References: <5294A8EB.1080101@redhat.com> Message-ID: <5294EE74.8000400@redhat.com> On 11/26/2013 09:17 AM, Andrew Lau wrote: > On Wed, Nov 27, 2013 at 12:58 AM, Rob Crittenden >wrote: > > Andrew Lau wrote: > > Hi, > > I've got an issue where I can't seem to remove a host from my > freeipa > install. It gives me an error: > > Certificate operation cannot be completed: EXCEPTION > (Certificate serial > number 0xfff0006 not found) > > I thought it might be a replica issue, so I forced sync and > also tried > re-initializing the replica but no luck. > > Any suggestions? > > > Deleting a host does a number of additional things: > - revokes the certificate for the host if it exists > - deletes the services for that host, revoking their certificates > as needed > > So in this case the host has a certificate associated with it and > revocation is failing because the CA doesn't have a record of this > certificate. > > If you can be sure that the certificate is not in the IPA CA you > can clear the value with: > > # ipa host-mod --certificate= test.example.com > > > This passes an empty value to --certificate which results in > removing the value. Then you should be able to delete the host. > > rob > > > Thanks that worked. > > Andrew. > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users Adding solved tag to subj. -- 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 siology.io at gmail.com Tue Nov 26 20:37:59 2013 From: siology.io at gmail.com (siology.io) Date: Wed, 27 Nov 2013 09:37:59 +1300 Subject: [Freeipa-users] ui timeout issue Message-ID: I'm seeing an issue with logging into the web UI of ipa. I've been using IPA for 6 months or so in production, and all has been well so far. The last thing i did in terms of IPA was run ipa-dns-install, which completed successfully, but i suspect this issue occured before that i never noticed as it's been a few weeks since i used the UI. I typically check the login page works and ldapsearch works after upgrades, but in this instance the login box is presented, and after entering the credentials it sits doing nothing for a while, then times out with 'internal server error' The only useful log i've managed to find is in /var/log/httpd/error_log [Wed Nov 27 08:41:47 2013] [error] [client (redacted)] Script timed out before returning headers: wsgi.py, referer: https://(redacted)/ipa/ui/ I'm seeing this behaviour on both my master and replica, but they are both identical in terms of package versions and such, so it may not be significant. My system versions: Centos 6.4 x64 ipa-python-3.0.0-26.el6_4.4.x86_64 ipa-server-selinux-3.0.0-26.el6_4.4.x86_64 python-iniparse-0.3.1-2.1.el6.noarch libipa_hbac-1.9.2-82.10.el6_4.x86_64 libipa_hbac-python-1.9.2-82.10.el6_4.x86_64 ipa-client-3.0.0-26.el6_4.4.x86_64 ipa-server-3.0.0-26.el6_4.4.x86_64 ipa-pki-ca-theme-9.0.3-7.el6.noarch ipa-admintools-3.0.0-26.el6_4.4.x86_64 ipa-pki-common-theme-9.0.3-7.el6.noarch bind-dyndb-ldap-2.3-2.el6_4.1.x86_64 bind-9.8.2-0.17.rc1.el6_4.6.x86_64 which are (afaik) all latest for centos 6.4 Oddly, i'm not seeing this behaviour in my virtualbox / vagrant IPA testbed, which has identical version numbers, and wsgi.py in /usr/share/ipa has identical md5sum. Not really sure how to approach debugging this further. Any ideas ? Has anyone else seen this happen ? The ldapsearch, bind dns and everything else seem operational - just the GUI is out of action. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Tue Nov 26 21:21:42 2013 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 26 Nov 2013 16:21:42 -0500 Subject: [Freeipa-users] ui timeout issue In-Reply-To: References: Message-ID: <529510E6.1010307@redhat.com> On 11/26/2013 03:37 PM, siology.io wrote: > I'm seeing an issue with logging into the web UI of ipa. I've been > using IPA for 6 months or so in production, and all has been well so > far. > > The last thing i did in terms of IPA was run ipa-dns-install, which > completed successfully, but i suspect this issue occured before that i > never noticed as it's been a few weeks since i used the UI. I > typically check the login page works and ldapsearch works after > upgrades, but in this instance the login box is presented, and after > entering the credentials it sits doing nothing for a while, then times > out with 'internal server error' > > The only useful log i've managed to find is in /var/log/httpd/error_log > > [Wed Nov 27 08:41:47 2013] [error] [client (redacted)] Script timed > out before returning headers: wsgi.py, referer: https://(redacted)/ipa/ui/ What happens before that in the log? Any DNS lookup or some other lookup? > > I'm seeing this behaviour on both my master and replica, but they are > both identical in terms of package versions and such, so it may not be > significant. > > My system versions: > Centos 6.4 x64 > > ipa-python-3.0.0-26.el6_4.4.x86_64 > ipa-server-selinux-3.0.0-26.el6_4.4.x86_64 > python-iniparse-0.3.1-2.1.el6.noarch > libipa_hbac-1.9.2-82.10.el6_4.x86_64 > libipa_hbac-python-1.9.2-82.10.el6_4.x86_64 > ipa-client-3.0.0-26.el6_4.4.x86_64 > ipa-server-3.0.0-26.el6_4.4.x86_64 > ipa-pki-ca-theme-9.0.3-7.el6.noarch > ipa-admintools-3.0.0-26.el6_4.4.x86_64 > ipa-pki-common-theme-9.0.3-7.el6.noarch > > bind-dyndb-ldap-2.3-2.el6_4.1.x86_64 > bind-9.8.2-0.17.rc1.el6_4.6.x86_64 > > which are (afaik) all latest for centos 6.4 > > Oddly, i'm not seeing this behaviour in my virtualbox / vagrant IPA > testbed, which has identical version numbers, and wsgi.py in > /usr/share/ipa has identical md5sum. > > Not really sure how to approach debugging this further. Any ideas ? > Has anyone else seen this happen ? > > The ldapsearch, bind dns and everything else seem operational - just > the GUI is out of action. > > > > > _______________________________________________ > 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 siology.io at gmail.com Tue Nov 26 21:32:04 2013 From: siology.io at gmail.com (siology.io) Date: Wed, 27 Nov 2013 10:32:04 +1300 Subject: [Freeipa-users] ui timeout issue In-Reply-To: <529510E6.1010307@redhat.com> References: <529510E6.1010307@redhat.com> Message-ID: On 27 November 2013 10:21, Dmitri Pal wrote: > On 11/26/2013 03:37 PM, siology.io wrote: > > I'm seeing an issue with logging into the web UI of ipa. I've been using > IPA for 6 months or so in production, and all has been well so far. > > The last thing i did in terms of IPA was run ipa-dns-install, which > completed successfully, but i suspect this issue occured before that i > never noticed as it's been a few weeks since i used the UI. I typically > check the login page works and ldapsearch works after upgrades, but in this > instance the login box is presented, and after entering the credentials it > sits doing nothing for a while, then times out with 'internal server error' > > The only useful log i've managed to find is in /var/log/httpd/error_log > > [Wed Nov 27 08:41:47 2013] [error] [client (redacted)] Script timed out > before returning headers: wsgi.py, referer: https://(redacted)/ipa/ui/ > > > What happens before that in the log? > Any DNS lookup or some other lookup? > > doesn't appear so, no. what makes you suspect that ? I never got as far as doing the ipa-dns-install on the replica. I did it on the master, then went to login and got this issue. It may well be that it (the UI) was broken previously. I couldn't work out how to remove the ipa-dns-install to find out if it magically resumes working though. > > > I'm seeing this behaviour on both my master and replica, but they are > both identical in terms of package versions and such, so it may not be > significant. > > My system versions: > Centos 6.4 x64 > > ipa-python-3.0.0-26.el6_4.4.x86_64 > ipa-server-selinux-3.0.0-26.el6_4.4.x86_64 > python-iniparse-0.3.1-2.1.el6.noarch > libipa_hbac-1.9.2-82.10.el6_4.x86_64 > libipa_hbac-python-1.9.2-82.10.el6_4.x86_64 > ipa-client-3.0.0-26.el6_4.4.x86_64 > ipa-server-3.0.0-26.el6_4.4.x86_64 > ipa-pki-ca-theme-9.0.3-7.el6.noarch > ipa-admintools-3.0.0-26.el6_4.4.x86_64 > ipa-pki-common-theme-9.0.3-7.el6.noarch > > bind-dyndb-ldap-2.3-2.el6_4.1.x86_64 > bind-9.8.2-0.17.rc1.el6_4.6.x86_64 > > which are (afaik) all latest for centos 6.4 > > Oddly, i'm not seeing this behaviour in my virtualbox / vagrant IPA > testbed, which has identical version numbers, and wsgi.py in /usr/share/ipa > has identical md5sum. > > Not really sure how to approach debugging this further. Any ideas ? Has > anyone else seen this happen ? > > The ldapsearch, bind dns and everything else seem operational - just the > GUI is out of action. > > > > > > > > > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Tue Nov 26 21:47:19 2013 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 26 Nov 2013 16:47:19 -0500 Subject: [Freeipa-users] ui timeout issue In-Reply-To: References: <529510E6.1010307@redhat.com> Message-ID: <529516E7.3030300@redhat.com> On 11/26/2013 04:32 PM, siology.io wrote: > > > > On 27 November 2013 10:21, Dmitri Pal > wrote: > > On 11/26/2013 03:37 PM, siology.io wrote: >> I'm seeing an issue with logging into the web UI of ipa. I've >> been using IPA for 6 months or so in production, and all has been >> well so far. >> >> The last thing i did in terms of IPA was run ipa-dns-install, >> which completed successfully, but i suspect this issue occured >> before that i never noticed as it's been a few weeks since i used >> the UI. I typically check the login page works and ldapsearch >> works after upgrades, but in this instance the login box is >> presented, and after entering the credentials it sits doing >> nothing for a while, then times out with 'internal server error' >> >> The only useful log i've managed to find is in >> /var/log/httpd/error_log >> >> [Wed Nov 27 08:41:47 2013] [error] [client (redacted)] Script >> timed out before returning headers: wsgi.py, referer: >> https://(redacted)/ipa/ui/ > > What happens before that in the log? > Any DNS lookup or some other lookup? > > > doesn't appear so, no. what makes you suspect that ? I never got as > far as doing the ipa-dns-install on the replica. I did it on the > master, then went to login and got this issue. It may well be that it > (the UI) was broken previously. I couldn't work out how to remove the > ipa-dns-install to find out if it magically resumes working though. A pure speculation: If the UI presents you the form and you fill it then you are definitely talking to the server. When you submit the form the server tries to do kinit on your behalf. It might not be able to determine where its KDC because the DNS configuration is broken in some way and it is now looking at the wrong KDC (may be AD KDC or there is a lack of the server records at all for some reason). > > > >> >> I'm seeing this behaviour on both my master and replica, but they >> are both identical in terms of package versions and such, so it >> may not be significant. >> >> My system versions: >> Centos 6.4 x64 >> >> ipa-python-3.0.0-26.el6_4.4.x86_64 >> ipa-server-selinux-3.0.0-26.el6_4.4.x86_64 >> python-iniparse-0.3.1-2.1.el6.noarch >> libipa_hbac-1.9.2-82.10.el6_4.x86_64 >> libipa_hbac-python-1.9.2-82.10.el6_4.x86_64 >> ipa-client-3.0.0-26.el6_4.4.x86_64 >> ipa-server-3.0.0-26.el6_4.4.x86_64 >> ipa-pki-ca-theme-9.0.3-7.el6.noarch >> ipa-admintools-3.0.0-26.el6_4.4.x86_64 >> ipa-pki-common-theme-9.0.3-7.el6.noarch >> >> bind-dyndb-ldap-2.3-2.el6_4.1.x86_64 >> bind-9.8.2-0.17.rc1.el6_4.6.x86_64 >> >> which are (afaik) all latest for centos 6.4 >> >> Oddly, i'm not seeing this behaviour in my virtualbox / vagrant >> IPA testbed, which has identical version numbers, and wsgi.py in >> /usr/share/ipa has identical md5sum. >> >> Not really sure how to approach debugging this further. Any ideas >> ? Has anyone else seen this happen ? >> >> The ldapsearch, bind dns and everything else seem operational - >> just the GUI is out of action. > > > >> >> >> >> >> _______________________________________________ >> 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 -- 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 siology.io at gmail.com Tue Nov 26 22:00:31 2013 From: siology.io at gmail.com (siology.io) Date: Wed, 27 Nov 2013 11:00:31 +1300 Subject: [Freeipa-users] ui timeout issue In-Reply-To: <529516E7.3030300@redhat.com> References: <529510E6.1010307@redhat.com> <529516E7.3030300@redhat.com> Message-ID: yeah maybe. I do see from the install log of the ipa-dns-install that it changed the /etc/resolv.conf to point to its own ip - which seems a little odd (and unwanted, more importantly). I've changed that back to how it should be and restarted ipa but still nothing. There's no other KDC in the environment that i'm aware of. Certainly, the dns i was using only have the one set of SRV records for ldap and kdc. The bit that puzzles me is how/why that would have affected the replica server also. I asume it's copied the ldap dns data to the replica, but i never installed bind there or bind-dyndb-ldap, or anything else - so i'd expect that to be unaffected but it's also broken now. :-( On 27 November 2013 10:47, Dmitri Pal wrote: > On 11/26/2013 04:32 PM, siology.io wrote: > > > > > On 27 November 2013 10:21, Dmitri Pal wrote: > >> On 11/26/2013 03:37 PM, siology.io wrote: >> >> I'm seeing an issue with logging into the web UI of ipa. I've been using >> IPA for 6 months or so in production, and all has been well so far. >> >> The last thing i did in terms of IPA was run ipa-dns-install, which >> completed successfully, but i suspect this issue occured before that i >> never noticed as it's been a few weeks since i used the UI. I typically >> check the login page works and ldapsearch works after upgrades, but in this >> instance the login box is presented, and after entering the credentials it >> sits doing nothing for a while, then times out with 'internal server error' >> >> The only useful log i've managed to find is in /var/log/httpd/error_log >> >> [Wed Nov 27 08:41:47 2013] [error] [client (redacted)] Script timed out >> before returning headers: wsgi.py, referer: https://(redacted)/ipa/ui/ >> >> >> What happens before that in the log? >> Any DNS lookup or some other lookup? >> >> > doesn't appear so, no. what makes you suspect that ? I never got as far > as doing the ipa-dns-install on the replica. I did it on the master, then > went to login and got this issue. It may well be that it (the UI) was > broken previously. I couldn't work out how to remove the ipa-dns-install to > find out if it magically resumes working though. > > > > > A pure speculation: > If the UI presents you the form and you fill it then you are definitely > talking to the server. When you submit the form the server tries to do > kinit on your behalf. It might not be able to determine where its KDC > because the DNS configuration is broken in some way and it is now looking > at the wrong KDC (may be AD KDC or there is a lack of the server records at > all for some reason). > > > >> >> >> I'm seeing this behaviour on both my master and replica, but they are >> both identical in terms of package versions and such, so it may not be >> significant. >> >> My system versions: >> Centos 6.4 x64 >> >> ipa-python-3.0.0-26.el6_4.4.x86_64 >> ipa-server-selinux-3.0.0-26.el6_4.4.x86_64 >> python-iniparse-0.3.1-2.1.el6.noarch >> libipa_hbac-1.9.2-82.10.el6_4.x86_64 >> libipa_hbac-python-1.9.2-82.10.el6_4.x86_64 >> ipa-client-3.0.0-26.el6_4.4.x86_64 >> ipa-server-3.0.0-26.el6_4.4.x86_64 >> ipa-pki-ca-theme-9.0.3-7.el6.noarch >> ipa-admintools-3.0.0-26.el6_4.4.x86_64 >> ipa-pki-common-theme-9.0.3-7.el6.noarch >> >> bind-dyndb-ldap-2.3-2.el6_4.1.x86_64 >> bind-9.8.2-0.17.rc1.el6_4.6.x86_64 >> >> which are (afaik) all latest for centos 6.4 >> >> Oddly, i'm not seeing this behaviour in my virtualbox / vagrant IPA >> testbed, which has identical version numbers, and wsgi.py in /usr/share/ipa >> has identical md5sum. >> >> Not really sure how to approach debugging this further. Any ideas ? Has >> anyone else seen this happen ? >> >> The ldapsearch, bind dns and everything else seem operational - just >> the GUI is out of action. >> >> >> >> >> >> >> >> >> _______________________________________________ >> 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 >> > > > > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.bryant at melbourneit.com.au Tue Nov 26 22:14:04 2013 From: matthew.bryant at melbourneit.com.au (Matt Bryant) Date: Wed, 27 Nov 2013 08:14:04 +1000 Subject: [Freeipa-users] Intermittent Issues changing passwords since updating to ipa v3 and sasl_bind timeouts .. In-Reply-To: <20131126084128.GK3414@localhost.localdomain> References: <5293FF79.5@melbourneit.com.au> <52942C92.1040003@melbourneit.com.au> <20131126084128.GK3414@localhost.localdomain> Message-ID: <52951D2C.301@melbourneit.com.au> Sumit, Its a little tricky but ran up a script that did a ldapsearch every 2 seconds ... the following took place almost same time as one of the sasl_bind timeouts ... Start: .Wed Nov 27 07:55:03 EST 2013 ldap_url_parse_ext(ldap://tardis.ipa.server-noc.com) ldap_create ldap_url_parse_ext(ldap://tardis.ipa.server-noc.com:389/??base) ldap_sasl_interactive_bind_s: user selected: GSSAPI ldap_int_sasl_bind: GSSAPI ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP tardis.ipa.server-noc.com:389 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 203.147.190.30:389 ldap_pvt_connect: fd: 3 tm: 6 async: 0 ldap_ndelay_on: 3 ldap_int_poll: fd: 3 tm: 6 ldap_is_sock_ready: 3 ldap_ndelay_off: 3 ldap_pvt_connect: 0 ldap_int_sasl_open: host=tardis.ipa.server-noc.com SASL/GSSAPI authentication started ldap_sasl_bind_s ldap_sasl_bind ldap_send_initial_request ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({i) ber: ber_flush2: 692 bytes to sd 3 ldap_result ld 0xdbf4a0 msgid 1 wait4msg ld 0xdbf4a0 msgid 1 (infinite timeout) wait4msg continue ld 0xdbf4a0 msgid 1 all 1 ** ld 0xdbf4a0 Connections: * host: tardis.ipa.server-noc.com port: 389 (default) refcnt: 2 status: Connected last used: Wed Nov 27 07:55:03 2013 ** ld 0xdbf4a0 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ld 0xdbf4a0 request count 1 (abandoned 0) ** ld 0xdbf4a0 Response Queue: Empty ld 0xdbf4a0 response count 0 ldap_chkResponseList ld 0xdbf4a0 msgid 1 all 1 ldap_chkResponseList returns ld 0xdbf4a0 NULL ldap_int_select read1msg: ld 0xdbf4a0 msgid 1 all 1 ber_get_next ber_get_next: tag 0x30 len 172 contents: read1msg: ld 0xdbf4a0 msgid 1 message type bind ber_scanf fmt ({eAA) ber: read1msg: ld 0xdbf4a0 0 new referrals read1msg: mark request completed, ld 0xdbf4a0 msgid 1 request done: ld 0xdbf4a0 msgid 1 res_errno: 14, res_error: <>, res_matched: <> ldap_free_request (origid 1, msgid 1) ldap_parse_sasl_bind_result ber_scanf fmt ({eAA) ber: ber_scanf fmt (O) ber: ldap_parse_result ber_scanf fmt ({iAA) ber: ber_scanf fmt (x) ber: ber_scanf fmt (}) ber: ldap_msgfree sasl_client_step: 1 ldap_sasl_bind_s ldap_sasl_bind ldap_send_initial_request ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({i) ber: ber_flush2: 22 bytes to sd 3 ldap_result ld 0xdbf4a0 msgid 2 wait4msg ld 0xdbf4a0 msgid 2 (infinite timeout) wait4msg continue ld 0xdbf4a0 msgid 2 all 1 ** ld 0xdbf4a0 Connections: * host: tardis.ipa.server-noc.com port: 389 (default) refcnt: 2 status: Connected last used: Wed Nov 27 07:55:08 2013 ** ld 0xdbf4a0 Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ld 0xdbf4a0 request count 1 (abandoned 0) ** ld 0xdbf4a0 Response Queue: Empty ld 0xdbf4a0 response count 0 ldap_chkResponseList ld 0xdbf4a0 msgid 2 all 1 ldap_chkResponseList returns ld 0xdbf4a0 NULL ldap_int_select read1msg: ld 0xdbf4a0 msgid 2 all 1 ber_get_next ber_get_next: tag 0x30 len 46 contents: read1msg: ld 0xdbf4a0 msgid 2 message type bind ber_scanf fmt ({eAA) ber: read1msg: ld 0xdbf4a0 0 new referrals read1msg: mark request completed, ld 0xdbf4a0 msgid 2 request done: ld 0xdbf4a0 msgid 2 res_errno: 14, res_error: <>, res_matched: <> ldap_free_request (origid 2, msgid 2) ldap_parse_sasl_bind_result ber_scanf fmt ({eAA) ber: ber_scanf fmt (O) ber: ldap_parse_result ber_scanf fmt ({iAA) ber: ber_scanf fmt (x) ber: ber_scanf fmt (}) ber: ldap_msgfree sasl_client_step: 0 ldap_sasl_bind_s ldap_sasl_bind ldap_send_initial_request ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({i) ber: ber_flush2: 56 bytes to sd 3 ldap_result ld 0xdbf4a0 msgid 3 wait4msg ld 0xdbf4a0 msgid 3 (infinite timeout) wait4msg continue ld 0xdbf4a0 msgid 3 all 1 ** ld 0xdbf4a0 Connections: * host: tardis.ipa.server-noc.com port: 389 (default) refcnt: 2 status: Connected last used: Wed Nov 27 07:55:08 2013 ** ld 0xdbf4a0 Outstanding Requests: * msgid 3, origid 3, status InProgress outstanding referrals 0, parent count 0 ld 0xdbf4a0 request count 1 (abandoned 0) ** ld 0xdbf4a0 Response Queue: Empty ld 0xdbf4a0 response count 0 ldap_chkResponseList ld 0xdbf4a0 msgid 3 all 1 ldap_chkResponseList returns ld 0xdbf4a0 NULL ldap_int_select read1msg: ld 0xdbf4a0 msgid 3 all 1 ber_get_next ber_get_next: tag 0x30 len 12 contents: read1msg: ld 0xdbf4a0 msgid 3 message type bind ber_scanf fmt ({eAA) ber: read1msg: ld 0xdbf4a0 0 new referrals read1msg: mark request completed, ld 0xdbf4a0 msgid 3 request done: ld 0xdbf4a0 msgid 3 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 3, msgid 3) ldap_parse_sasl_bind_result ber_scanf fmt ({eAA) ber: ldap_parse_result ber_scanf fmt ({iAA) ber: ber_scanf fmt (}) ber: ldap_msgfree SASL username: host/tardis.ipa.server-noc.com at SERVER-IPA SASL SSF: 56 ldap_pvt_sasl_generic_install SASL data security layer installed. ldap_search_ext put_filter: "uid=admin" put_filter: default put_simple_filter: "uid=admin" ldap_send_initial_request ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({) ber: ber_flush2: 53 bytes to sd 3 ldap_result ld 0xdbf4a0 msgid -1 wait4msg ld 0xdbf4a0 msgid -1 (infinite timeout) wait4msg continue ld 0xdbf4a0 msgid -1 all 0 ** ld 0xdbf4a0 Connections: * host: tardis.ipa.server-noc.com port: 389 (default) refcnt: 2 status: Connected last used: Wed Nov 27 07:55:08 2013 ** ld 0xdbf4a0 Outstanding Requests: * msgid 4, origid 4, status InProgress outstanding referrals 0, parent count 0 ld 0xdbf4a0 request count 1 (abandoned 0) ** ld 0xdbf4a0 Response Queue: Empty ld 0xdbf4a0 response count 0 ldap_chkResponseList ld 0xdbf4a0 msgid -1 all 0 ldap_chkResponseList returns ld 0xdbf4a0 NULL ldap_int_select read1msg: ld 0xdbf4a0 msgid -1 all 0 ber_get_next ber_get_next: tag 0x30 len 268 contents: read1msg: ld 0xdbf4a0 msgid 4 message type search-entry ldap_get_dn_ber ber_scanf fmt ({ml{) ber: ldap_dn2ufn ldap_dn_normalize ber_scanf fmt ({xx) ber: ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: ldap_get_attribute_ber ldap_msgfree ldap_result ld 0xdbf4a0 msgid -1 wait4msg ld 0xdbf4a0 msgid -1 (infinite timeout) wait4msg continue ld 0xdbf4a0 msgid -1 all 0 ** ld 0xdbf4a0 Connections: * host: tardis.ipa.server-noc.com port: 389 (default) refcnt: 2 status: Connected last used: Wed Nov 27 07:55:08 2013 ** ld 0xdbf4a0 Outstanding Requests: * msgid 4, origid 4, status InProgress outstanding referrals 0, parent count 0 ld 0xdbf4a0 request count 1 (abandoned 0) ** ld 0xdbf4a0 Response Queue: Empty ld 0xdbf4a0 response count 0 ldap_chkResponseList ld 0xdbf4a0 msgid -1 all 0 ldap_chkResponseList returns ld 0xdbf4a0 NULL ldap_int_select read1msg: ld 0xdbf4a0 msgid -1 all 0 ber_get_next ber_get_next: tag 0x30 len 1518 contents: read1msg: ld 0xdbf4a0 msgid 4 message type search-entry ldap_get_dn_ber ber_scanf fmt ({ml{) ber: ldap_dn2ufn ldap_dn_normalize ber_scanf fmt ({xx) ber: ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: ldap_get_attribute_ber ldap_msgfree ldap_result ld 0xdbf4a0 msgid -1 wait4msg ld 0xdbf4a0 msgid -1 (infinite timeout) wait4msg continue ld 0xdbf4a0 msgid -1 all 0 ** ld 0xdbf4a0 Connections: * host: tardis.ipa.server-noc.com port: 389 (default) refcnt: 2 status: Connected last used: Wed Nov 27 07:55:08 2013 ** ld 0xdbf4a0 Outstanding Requests: * msgid 4, origid 4, status InProgress outstanding referrals 0, parent count 0 ld 0xdbf4a0 request count 1 (abandoned 0) ** ld 0xdbf4a0 Response Queue: Empty ld 0xdbf4a0 response count 0 ldap_chkResponseList ld 0xdbf4a0 msgid -1 all 0 ldap_chkResponseList returns ld 0xdbf4a0 NULL ldap_int_select read1msg: ld 0xdbf4a0 msgid -1 all 0 ber_get_next ber_get_next: tag 0x30 len 12 contents: read1msg: ld 0xdbf4a0 msgid 4 message type search-result ber_scanf fmt ({eAA) ber: read1msg: ld 0xdbf4a0 0 new referrals read1msg: mark request completed, ld 0xdbf4a0 msgid 4 request done: ld 0xdbf4a0 msgid 4 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 4, msgid 4) ldap_parse_result ber_scanf fmt ({iAA) ber: ber_scanf fmt (}) ber: ldap_err2string ldap_msgfree ldap_free_connection 1 1 ldap_send_unbind ber_flush2: 7 bytes to sd 3 ldap_free_connection: actually freed # extended LDIF # # LDAPv3 # base with scope subtree # filter: uid=admin # requesting: ALL # # admin, users, compat, server-ipa dn: uid=admin,cn=users,cn=compat,dc=server-ipa objectClass: posixAccount objectClass: top gecos: Administrator cn: Administrator uidNumber: xxxxxxxx gidNumber: xxxxxxxx loginShell: /bin/bash homeDirectory: /home/admin uid: admin # admin, users, accounts, server-ipa dn: uid=admin,cn=users,cn=accounts,dc=server-ipa krbLastSuccessfulAuth: 20131124214435Z krbLoginFailedCount: 0 krbLastFailedAuth: 20131014050743Z memberOf: cn=admins,cn=groups,cn=accounts,dc=server-ipa memberOf: cn=replication administrators,cn=privileges,cn=pbac,dc=server-ipa memberOf: cn=add replication agreements,cn=permissions,cn=pbac,dc=server-ipa memberOf: cn=modify replication agreements,cn=permissions,cn=pbac,dc=server-ip a memberOf: cn=remove replication agreements,cn=permissions,cn=pbac,dc=server-ip a memberOf: cn=host enrollment,cn=privileges,cn=pbac,dc=server-ipa memberOf: cn=manage host keytab,cn=permissions,cn=pbac,dc=server-ipa memberOf: cn=enroll a host,cn=permissions,cn=pbac,dc=server-ipa memberOf: cn=add krbprincipalname to a host,cn=permissions,cn=pbac,dc=server-i pa memberOf: cn=unlock user accounts,cn=permissions,cn=pbac,dc=server-ipa memberOf: cn=manage service keytab,cn=permissions,cn=pbac,dc=server-ipa memberOf: cn=trust admins,cn=groups,cn=accounts,dc=server-ipa krbPasswordExpiration: 20140108225426Z krbExtraData:: xxxxxxxxxx krbTicketFlags: 128 krbLastPwdChange: 20131010225426Z objectClass: top objectClass: person objectClass: posixaccount objectClass: krbprincipalaux objectClass: krbticketpolicyaux objectClass: inetuser objectClass: ipaobject objectClass: ipasshuser objectClass: ipaSshGroupOfPubKeys uid: admin krbPrincipalName: admin at SERVER-IPA cn: Administrator sn: Administrator uidNumber: xxxxxxxx gidNumber: xxxxxxxx homeDirectory: /home/admin loginShell: /bin/bash gecos: Administrator ipaUniqueID: xxxxxxxxxxxxxxx # search result search: 4 result: 0 Success # numResponses: 3 # numEntries: 2 End: .Wed Nov 27 07:55:08 EST 2013 the whole thing still takes < 6secs but most are coming back within the same second .. and the point it seems to slow down around is the initial ldap_int_select ... ldap_int_select read1msg: ld 0xdbf4a0 msgid 1 all 1 ber_get_next rgds Matt B. On 11/26/2013 06:41 PM, Sumit Bose wrote: > On Tue, Nov 26, 2013 at 03:07:30PM +1000, Matt Bryant wrote: >> OK so been running some tcpdumps on this issue and the wierd thing is .. >> >> can see the initial sasl bind request followed by ack from ldap ... >> then nothing ldap/gssapi related until the unbind request post the >> 6s timeout period ... >> >> so no friggin idea whats going on just a big resounding nothing ... >> >> 14:20:47.065606 IP tardis.ipa.server-noc.com.40953 > >> tardis.ipa.server-noc.com.ldap: Flags [P.], seq 261:974, ack 1502, >> win 280, options [nop,nop,TS val 23677005 ecr 23676785], length 713 >> 14:20:47.104816 IP tardis.ipa.server-noc.com.ldap > >> tardis.ipa.server-noc.com.40953: Flags [.], ack 974, win 276, >> options [nop,nop,TS val 23677045 ecr 23677005], length 0 >> 14:20:53.066009 IP tardis.ipa.server-noc.com.40953 > >> tardis.ipa.server-noc.com.ldap: Flags [P.], seq 974:981, ack 1502, >> win 280, options [nop,nop,TS val 23683006 ecr 23677045], length 7 >> 14:20:53.066021 IP tardis.ipa.server-noc.com.ldap > >> tardis.ipa.server-noc.com.40953: Flags [.], ack 981, win 276, >> options [nop,nop,TS val 23683006 ecr 23683006], length 0 >> 14:20:53.066100 IP tardis.ipa.server-noc.com.40953 > >> tardis.ipa.server-noc.com.ldap: Flags [F.], seq 981, ack 1502, win >> 280, options [nop,nop,TS val 23683006 ecr 23683006], length 0 >> 14:20:53.105731 IP tardis.ipa.server-noc.com.ldap > >> tardis.ipa.server-noc.com.40953: Flags [.], ack 982, win 276, >> options [nop,nop,TS val 23683046 ecr 23683006], length 0 >> 14:20:53.111470 IP tardis.ipa.server-noc.com.ldap > >> tardis.ipa.server-noc.com.40953: Flags [F.], seq 1502, ack 982, win >> 276, options [nop,nop,TS val 23683051 ecr 23683006], length 0 >> 14:20:53.111486 IP tardis.ipa.server-noc.com.40953 > >> tardis.ipa.server-noc.com.ldap: Flags [.], ack 1503, win 280, >> options [nop,nop,TS val 23683051 ecr 23683051], length 0 >> >> Comparing that to a connection that works and brings the backend online .. >> >> 14:22:01.193809 IP tardis.ipa.server-noc.com.41031 > >> tardis.ipa.server-noc.com.ldap: Flags [S], seq 3387425755, win >> 32792, options [mss 16396,sackOK,TS val 23751134 ecr 0,nop,wscale >> 7], length 0 >> 14:22:01.193833 IP tardis.ipa.server-noc.com.ldap > >> tardis.ipa.server-noc.com.41031: Flags [S.], seq 1024653772, ack >> 3387425756, win 32768, options [mss 16396,sackOK,TS val 23751134 ecr >> 23751134,nop,wscale 7], length 0 >> 14:22:01.193848 IP tardis.ipa.server-noc.com.41031 > >> tardis.ipa.server-noc.com.ldap: Flags [.], ack 1, win 257, options >> [nop,nop,TS val 23751134 ecr 23751134], length 0 >> 14:22:01.194371 IP tardis.ipa.server-noc.com.41031 > >> tardis.ipa.server-noc.com.ldap: Flags [P.], seq 1:261, ack 1, win >> 257, options [nop,nop,TS val 23751134 ecr 23751134], length 260 >> 14:22:01.194385 IP tardis.ipa.server-noc.com.ldap > >> tardis.ipa.server-noc.com.41031: Flags [.], ack 261, win 265, >> options [nop,nop,TS val 23751134 ecr 23751134], length 0 >> 14:22:01.195187 IP tardis.ipa.server-noc.com.ldap > >> tardis.ipa.server-noc.com.41031: Flags [P.], seq 1:1502, ack 261, >> win 265, options [nop,nop,TS val 23751135 ecr 23751134], length 1501 >> 14:22:01.195201 IP tardis.ipa.server-noc.com.41031 > >> tardis.ipa.server-noc.com.ldap: Flags [.], ack 1502, win 280, >> options [nop,nop,TS val 23751135 ecr 23751135], length 0 >> 14:22:01.443288 IP tardis.ipa.server-noc.com.41031 > >> tardis.ipa.server-noc.com.ldap: Flags [P.], seq 261:953, ack 1502, >> win 280, options [nop,nop,TS val 23751383 ecr 23751135], length 692 >> 14:22:01.470047 IP tardis.ipa.server-noc.com.ldap > >> tardis.ipa.server-noc.com.41031: Flags [P.], seq 1502:1677, ack 953, >> win 276, options [nop,nop,TS val 23751410 ecr 23751383], length 175 >> 14:22:01.470062 IP tardis.ipa.server-noc.com.41031 > >> tardis.ipa.server-noc.com.ldap: Flags [.], ack 1677, win 304, >> options [nop,nop,TS val 23751410 ecr 23751410], length 0 >> 14:22:01.470469 IP tardis.ipa.server-noc.com.41031 > >> tardis.ipa.server-noc.com.ldap: Flags [P.], seq 953:975, ack 1677, >> win 304, options [nop,nop,TS val 23751410 ecr 23751410], length 22 >> 14:22:01.471249 IP tardis.ipa.server-noc.com.ldap > >> tardis.ipa.server-noc.com.41031: Flags [P.], seq 1677:1725, ack 975, >> win 276, options [nop,nop,TS val 23751411 ecr 23751410], length 48 >> 14:22:01.471298 IP tardis.ipa.server-noc.com.41031 > >> tardis.ipa.server-noc.com.ldap: Flags [P.], seq 975:1031, ack 1725, >> win 304, options [nop,nop,TS val 23751411 ecr 23751411], length 56 >> 14:22:01.484334 IP tardis.ipa.server-noc.com.ldap > >> tardis.ipa.server-noc.com.41031: Flags [P.], seq 1725:1739, ack >> 1031, win 276, options [nop,nop,TS val 23751424 ecr 23751411], >> length 14 >> 14:22:01.485505 IP tardis.ipa.server-noc.com.41031 > >> tardis.ipa.server-noc.com.ldap: Flags [P.], seq 1031:1656, ack 1739, >> win 304, options [nop,nop,TS val 23751425 ecr 23751424], length 625 >> 14:22:01.486736 IP tardis.ipa.server-noc.com.41031 > >> tardis.ipa.server-noc.com.ldap: Flags [P.], seq 1656:2284, ack 1739, >> win 304, options [nop,nop,TS val 23751427 ecr 23751424], length 628 >> 14:22:01.486747 IP tardis.ipa.server-noc.com.ldap > >> tardis.ipa.server-noc.com.41031: Flags [.], ack 2284, win 297, >> options [nop,nop,TS val 23751427 ecr 23751425], length 0 >> 14:22:01.516185 IP tardis.ipa.server-noc.com.41031 > >> tardis.ipa.server-noc.com.ldap: Flags [P.], seq 2284:2474, ack 1739, >> win 304, options [nop,nop,TS val 23751456 ecr 23751427], length 190 >> 14:22:01.555664 IP tardis.ipa.server-noc.com.ldap > >> tardis.ipa.server-noc.com.41031: Flags [.], ack 2474, win 308, >> options [nop,nop,TS val 23751496 ecr 23751456], length 0 >> 14:22:07.487451 IP tardis.ipa.server-noc.com.41031 > >> tardis.ipa.server-noc.com.ldap: Flags [P.], seq 2474:2546, ack 1739, >> win 304, options [nop,nop,TS val 23757427 ecr 23751496], length 72 >> 14:22:07.487467 IP tardis.ipa.server-noc.com.ldap > >> tardis.ipa.server-noc.com.41031: Flags [.], ack 2546, win 308, >> options [nop,nop,TS val 23757427 ecr 23757427], length 0 >> 14:22:07.487983 IP tardis.ipa.server-noc.com.41031 > >> tardis.ipa.server-noc.com.ldap: Flags [P.], seq 2546:2618, ack 1739, >> win 304, options [nop,nop,TS val 23757428 ecr 23757427], length 72 >> 14:22:07.487994 IP tardis.ipa.server-noc.com.ldap > >> tardis.ipa.server-noc.com.41031: Flags [.], ack 2618, win 308, >> options [nop,nop,TS val 23757428 ecr 23757428], length 0 >> 14:22:07.516863 IP tardis.ipa.server-noc.com.41031 > >> tardis.ipa.server-noc.com.ldap: Flags [P.], seq 2618:2690, ack 1739, >> win 304, options [nop,nop,TS val 23757457 ecr 23757428], length 72 >> 14:22:07.516883 IP tardis.ipa.server-noc.com.ldap > >> tardis.ipa.server-noc.com.41031: Flags [.], ack 2690, win 308, >> options [nop,nop,TS val 23757457 ecr 23757457], length 0 >> 14:22:07.517102 IP tardis.ipa.server-noc.com.41031 > >> tardis.ipa.server-noc.com.ldap: Flags [P.], seq 2690:2761, ack 1739, >> win 304, options [nop,nop,TS val 23757457 ecr 23757457], length 71 >> 14:22:07.517116 IP tardis.ipa.server-noc.com.ldap > >> tardis.ipa.server-noc.com.41031: Flags [.], ack 2761, win 308, >> options [nop,nop,TS val 23757457 ecr 23757457], length 0 >> 14:22:07.517573 IP tardis.ipa.server-noc.com.41031 > >> tardis.ipa.server-noc.com.ldap: Flags [F.], seq 2761, ack 1739, win >> 304, options [nop,nop,TS val 23757457 ecr 23757457], length 0 >> 14:22:07.556841 IP tardis.ipa.server-noc.com.ldap > >> tardis.ipa.server-noc.com.41031: Flags [.], ack 2762, win 308, >> options [nop,nop,TS val 23757497 ecr 23757457], length 0 >> 14:22:13.497311 IP tardis.ipa.server-noc.com.ldap > >> tardis.ipa.server-noc.com.41031: Flags [P.], seq 1739:1817, ack >> 2762, win 308, options [nop,nop,TS val 23763437 ecr 23757457], >> length 78 >> 14:22:13.497333 IP tardis.ipa.server-noc.com.41031 > >> tardis.ipa.server-noc.com.ldap: Flags [R], seq 3387428517, win 0, >> length 0 >> 14:22:13.526895 IP tardis.ipa.server-noc.com.ldap > >> tardis.ipa.server-noc.com.41031: Flags [R.], seq 1817, ack 2762, win >> 308, options [nop,nop,TS val 23763467 ecr 23757457], length 0 >> >> which using the ol' wireshark relate to >> >> bind request with a bind response traversing back and fro from ldap >> server till a bind success from ldap server and the query/queries >> run .. so to me it seems that there are times (and quite a few of >> them) where a bind request gets no response back from the server ... >> >> Has anyone seen this ... > no, I have not seen this. Some general comments about the SSSD log > files. The ldap_child only handles the part of getting a Kerberos > ticket. The complete bind happens inside the OpenLDAP ldap_sasl_bind() > call where we currently do not get any debug output from. > > Can you try if you see the same delay with the ldapsearch command line > utility? You can use the same credentials as SSSD if you call e.g: > > KRB5CCNAME=FILE:/var/lib/sss/db/ccache_YOUR.DOMAIN ldapsearch -Y GSSAPI \ > -H ldap://your.ipa.server -b 'dc=ipa,dc=domain' uid=admin > > If it can be reproduced with ldapsearch you can use the option '-d -1' > to get full debug output. > > I wonder if your server is a busy on handling lots of encrypted > connections? In this case, depending on how the session keys for those > connections are generated, the entropy pool might be too small to > generate a sufficient amount of random data for the keys which would > lead to a timeout in the application until enough entropy is gathered. > But I have to admit that I do not know which source of random data 389ds > is using. > > bye, > Sumit > >> rgds >> >> Matt B. >> > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From siology.io at gmail.com Tue Nov 26 22:15:18 2013 From: siology.io at gmail.com (siology.io) Date: Wed, 27 Nov 2013 11:15:18 +1300 Subject: [Freeipa-users] ui timeout issue In-Reply-To: References: <529510E6.1010307@redhat.com> <529516E7.3030300@redhat.com> Message-ID: for what it's worth, kinit on the command line of the ipa server works just fine, and detects the realm ok. On 27 November 2013 11:00, siology.io wrote: > yeah maybe. I do see from the install log of the ipa-dns-install that it > changed the /etc/resolv.conf to point to its own ip - which seems a little > odd (and unwanted, more importantly). I've changed that back to how it > should be and restarted ipa but still nothing. > > There's no other KDC in the environment that i'm aware of. Certainly, the > dns i was using only have the one set of SRV records for ldap and kdc. > > The bit that puzzles me is how/why that would have affected the replica > server also. I asume it's copied the ldap dns data to the replica, but i > never installed bind there or bind-dyndb-ldap, or anything else - so i'd > expect that to be unaffected but it's also broken now. :-( > > > On 27 November 2013 10:47, Dmitri Pal wrote: > >> On 11/26/2013 04:32 PM, siology.io wrote: >> >> >> >> >> On 27 November 2013 10:21, Dmitri Pal wrote: >> >>> On 11/26/2013 03:37 PM, siology.io wrote: >>> >>> I'm seeing an issue with logging into the web UI of ipa. I've been using >>> IPA for 6 months or so in production, and all has been well so far. >>> >>> The last thing i did in terms of IPA was run ipa-dns-install, which >>> completed successfully, but i suspect this issue occured before that i >>> never noticed as it's been a few weeks since i used the UI. I typically >>> check the login page works and ldapsearch works after upgrades, but in this >>> instance the login box is presented, and after entering the credentials it >>> sits doing nothing for a while, then times out with 'internal server error' >>> >>> The only useful log i've managed to find is in /var/log/httpd/error_log >>> >>> [Wed Nov 27 08:41:47 2013] [error] [client (redacted)] Script timed >>> out before returning headers: wsgi.py, referer: >>> https://(redacted)/ipa/ui/ >>> >>> >>> What happens before that in the log? >>> Any DNS lookup or some other lookup? >>> >>> >> doesn't appear so, no. what makes you suspect that ? I never got as far >> as doing the ipa-dns-install on the replica. I did it on the master, then >> went to login and got this issue. It may well be that it (the UI) was >> broken previously. I couldn't work out how to remove the ipa-dns-install to >> find out if it magically resumes working though. >> >> >> >> >> A pure speculation: >> If the UI presents you the form and you fill it then you are definitely >> talking to the server. When you submit the form the server tries to do >> kinit on your behalf. It might not be able to determine where its KDC >> because the DNS configuration is broken in some way and it is now looking >> at the wrong KDC (may be AD KDC or there is a lack of the server records at >> all for some reason). >> >> >> >>> >>> >>> I'm seeing this behaviour on both my master and replica, but they are >>> both identical in terms of package versions and such, so it may not be >>> significant. >>> >>> My system versions: >>> Centos 6.4 x64 >>> >>> ipa-python-3.0.0-26.el6_4.4.x86_64 >>> ipa-server-selinux-3.0.0-26.el6_4.4.x86_64 >>> python-iniparse-0.3.1-2.1.el6.noarch >>> libipa_hbac-1.9.2-82.10.el6_4.x86_64 >>> libipa_hbac-python-1.9.2-82.10.el6_4.x86_64 >>> ipa-client-3.0.0-26.el6_4.4.x86_64 >>> ipa-server-3.0.0-26.el6_4.4.x86_64 >>> ipa-pki-ca-theme-9.0.3-7.el6.noarch >>> ipa-admintools-3.0.0-26.el6_4.4.x86_64 >>> ipa-pki-common-theme-9.0.3-7.el6.noarch >>> >>> bind-dyndb-ldap-2.3-2.el6_4.1.x86_64 >>> bind-9.8.2-0.17.rc1.el6_4.6.x86_64 >>> >>> which are (afaik) all latest for centos 6.4 >>> >>> Oddly, i'm not seeing this behaviour in my virtualbox / vagrant IPA >>> testbed, which has identical version numbers, and wsgi.py in /usr/share/ipa >>> has identical md5sum. >>> >>> Not really sure how to approach debugging this further. Any ideas ? >>> Has anyone else seen this happen ? >>> >>> The ldapsearch, bind dns and everything else seem operational - just >>> the GUI is out of action. >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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 >>> >> >> >> >> _______________________________________________ >> 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 >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Tue Nov 26 23:51:28 2013 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 26 Nov 2013 18:51:28 -0500 Subject: [Freeipa-users] ui timeout issue In-Reply-To: References: <529510E6.1010307@redhat.com> <529516E7.3030300@redhat.com> Message-ID: <52953400.2010308@redhat.com> On 11/26/2013 05:15 PM, siology.io wrote: > for what it's worth, kinit on the command line of the ipa server works > just fine, and detects the realm ok. OK then let us rule out DNS for a moment. Have you checked the KDC log to see whether the authentication actually occurred? If kinit works, I suspect it works too but worth checking. May be there are some problems with memcached after the form based authentication to cache the authentication. KDC log would show whether the kinit and follow up service ticket request for LDAP access actually occurred. Also what about SELinux any suspicious AVC? > > > > > On 27 November 2013 11:00, siology.io > > wrote: > > yeah maybe. I do see from the install log of the ipa-dns-install > that it changed the /etc/resolv.conf to point to its own ip - > which seems a little odd (and unwanted, more importantly). I've > changed that back to how it should be and restarted ipa but still > nothing. > > There's no other KDC in the environment that i'm aware of. > Certainly, the dns i was using only have the one set of SRV > records for ldap and kdc. > > The bit that puzzles me is how/why that would have affected the > replica server also. I asume it's copied the ldap dns data to the > replica, but i never installed bind there or bind-dyndb-ldap, or > anything else - so i'd expect that to be unaffected but it's also > broken now. :-( > > > On 27 November 2013 10:47, Dmitri Pal > wrote: > > On 11/26/2013 04:32 PM, siology.io wrote: >> >> >> >> On 27 November 2013 10:21, Dmitri Pal > > wrote: >> >> On 11/26/2013 03:37 PM, siology.io >> wrote: >>> I'm seeing an issue with logging into the web UI of ipa. >>> I've been using IPA for 6 months or so in production, >>> and all has been well so far. >>> >>> The last thing i did in terms of IPA was run >>> ipa-dns-install, which completed successfully, but i >>> suspect this issue occured before that i never noticed >>> as it's been a few weeks since i used the UI. I >>> typically check the login page works and ldapsearch >>> works after upgrades, but in this instance the login box >>> is presented, and after entering the credentials it sits >>> doing nothing for a while, then times out with 'internal >>> server error' >>> >>> The only useful log i've managed to find is in >>> /var/log/httpd/error_log >>> >>> [Wed Nov 27 08:41:47 2013] [error] [client (redacted)] >>> Script timed out before returning headers: wsgi.py, >>> referer: https://(redacted)/ipa/ui/ >>> >> >> What happens before that in the log? >> Any DNS lookup or some other lookup? >> >> >> doesn't appear so, no. what makes you suspect that ? I never >> got as far as doing the ipa-dns-install on the replica. I did >> it on the master, then went to login and got this issue. It >> may well be that it (the UI) was broken previously. I >> couldn't work out how to remove the ipa-dns-install to find >> out if it magically resumes working though. > > > > A pure speculation: > If the UI presents you the form and you fill it then you are > definitely talking to the server. When you submit the form the > server tries to do kinit on your behalf. It might not be able > to determine where its KDC because the DNS configuration is > broken in some way and it is now looking at the wrong KDC (may > be AD KDC or there is a lack of the server records at all for > some reason). > >> >> >> >>> >>> I'm seeing this behaviour on both my master and replica, >>> but they are both identical in terms of package versions >>> and such, so it may not be significant. >>> >>> My system versions: >>> Centos 6.4 x64 >>> >>> ipa-python-3.0.0-26.el6_4.4.x86_64 >>> ipa-server-selinux-3.0.0-26.el6_4.4.x86_64 >>> python-iniparse-0.3.1-2.1.el6.noarch >>> libipa_hbac-1.9.2-82.10.el6_4.x86_64 >>> libipa_hbac-python-1.9.2-82.10.el6_4.x86_64 >>> ipa-client-3.0.0-26.el6_4.4.x86_64 >>> ipa-server-3.0.0-26.el6_4.4.x86_64 >>> ipa-pki-ca-theme-9.0.3-7.el6.noarch >>> ipa-admintools-3.0.0-26.el6_4.4.x86_64 >>> ipa-pki-common-theme-9.0.3-7.el6.noarch >>> >>> bind-dyndb-ldap-2.3-2.el6_4.1.x86_64 >>> bind-9.8.2-0.17.rc1.el6_4.6.x86_64 >>> >>> which are (afaik) all latest for centos 6.4 >>> >>> Oddly, i'm not seeing this behaviour in my virtualbox / >>> vagrant IPA testbed, which has identical version >>> numbers, and wsgi.py in /usr/share/ipa has identical md5sum. >>> >>> Not really sure how to approach debugging this further. >>> Any ideas ? Has anyone else seen this happen ? >>> >>> The ldapsearch, bind dns and everything else seem >>> operational - just the GUI is out of action. >> >> >> >>> >>> >>> >>> >>> _______________________________________________ >>> 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 > > > -- > 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 -- 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 matthew.bryant at melbourneit.com.au Wed Nov 27 01:24:36 2013 From: matthew.bryant at melbourneit.com.au (Matt Bryant) Date: Wed, 27 Nov 2013 11:24:36 +1000 Subject: [Freeipa-users] Trust between IPA and another MIT Kerberos Realm Message-ID: <529549D4.6020001@melbourneit.com.au> All, Is there any documentation anywhere that describes whether this can be done and how to do it ?? Would like to set up a one way trust between a new IPA realm and a legacy kerberos realm. The doco explicitly says dont use kadmin/kadmin.local so not sure how to get the krbtgt/OLD_REALM at IPA-REALM principle into IPA that would facilitate such a trust. rgds Matt B. From rcritten at redhat.com Wed Nov 27 03:57:06 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 26 Nov 2013 22:57:06 -0500 Subject: [Freeipa-users] Trust between IPA and another MIT Kerberos Realm In-Reply-To: <529549D4.6020001@melbourneit.com.au> References: <529549D4.6020001@melbourneit.com.au> Message-ID: <52956D92.3030606@redhat.com> Matt Bryant wrote: > All, > > Is there any documentation anywhere that describes whether this can be > done and how to do it ?? Would like to set up a one way trust between a > new IPA realm and a legacy kerberos realm. The doco explicitly says dont > use kadmin/kadmin.local so not sure how to get the > krbtgt/OLD_REALM at IPA-REALM principle into IPA that would facilitate such > a trust. We haven't implemented (or tested) this yet. It is just MIT Kerberos under-the-hood so in theory creating the right principals should do the trick. If you have IPA 3.0+ then you can use kadmin to create the principals you need. IIRC the RHEL Kerberos documentation is fairly good in this regard. rob From matthew.bryant at melbourneit.com.au Wed Nov 27 05:24:49 2013 From: matthew.bryant at melbourneit.com.au (Matt Bryant) Date: Wed, 27 Nov 2013 15:24:49 +1000 Subject: [Freeipa-users] Trust between IPA and another MIT Kerberos Realm In-Reply-To: <52956D92.3030606@redhat.com> References: <529549D4.6020001@melbourneit.com.au> <52956D92.3030606@redhat.com> Message-ID: <52958221.4030809@melbourneit.com.au> Hmm just upgraded to 3 so thought I woudl give it a go ... but (aint there always one of those :() can't seem to add the principle .. kadmin.local: add_principal krbtgt/OLD-REALM at IPA-REALM WARNING: no policy specified for krbtgt/OLD-REALM at IPA-REALM; defaulting to no policy Enter password for principal "krbtgt/OLD-REALM at IPA-REALM": Re-enter password for principal "krbtgt/OLD-REALM at IPA-REALM": add_principal: Invalid argument while creating "krbtgt/OLD-REALM at IPA-REALM". and nothing was placed in the kadmin log .. :( rgds Matt B. On 11/27/2013 01:57 PM, Rob Crittenden wrote: > Matt Bryant wrote: >> All, >> >> Is there any documentation anywhere that describes whether this can be >> done and how to do it ?? Would like to set up a one way trust between a >> new IPA realm and a legacy kerberos realm. The doco explicitly says dont >> use kadmin/kadmin.local so not sure how to get the >> krbtgt/OLD_REALM at IPA-REALM principle into IPA that would facilitate such >> a trust. > > We haven't implemented (or tested) this yet. It is just MIT Kerberos > under-the-hood so in theory creating the right principals should do > the trick. > > If you have IPA 3.0+ then you can use kadmin to create the principals > you need. IIRC the RHEL Kerberos documentation is fairly good in this > regard. > > rob From mkosek at redhat.com Wed Nov 27 07:47:51 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 27 Nov 2013 08:47:51 +0100 Subject: [Freeipa-users] ui timeout issue In-Reply-To: <52953400.2010308@redhat.com> References: <529510E6.1010307@redhat.com> <529516E7.3030300@redhat.com> <52953400.2010308@redhat.com> Message-ID: <5295A3A7.4020503@redhat.com> On 11/27/2013 12:51 AM, Dmitri Pal wrote: > On 11/26/2013 05:15 PM, siology.io wrote: >> for what it's worth, kinit on the command line of the ipa server works >> just fine, and detects the realm ok. > > OK then let us rule out DNS for a moment. > > Have you checked the KDC log to see whether the authentication actually > occurred? > If kinit works, I suspect it works too but worth checking. > > May be there are some problems with memcached after the form based > authentication to cache the authentication. KDC log would show whether > the kinit and follow up service ticket request for LDAP access actually > occurred. This is a good suggestion. Please see if ipa_memcached daemon is running, there was a glitch in one of the upgrades in the past which did not configure it correctly. If it is not, I can advise how to fix it. Martin From simo at redhat.com Wed Nov 27 13:05:16 2013 From: simo at redhat.com (Simo Sorce) Date: Wed, 27 Nov 2013 08:05:16 -0500 Subject: [Freeipa-users] Trust between IPA and another MIT Kerberos Realm In-Reply-To: <52958221.4030809@melbourneit.com.au> References: <529549D4.6020001@melbourneit.com.au> <52956D92.3030606@redhat.com> <52958221.4030809@melbourneit.com.au> Message-ID: <1385557516.22025.80.camel@willson.li.ssimo.org> On Wed, 2013-11-27 at 15:24 +1000, Matt Bryant wrote: > Hmm just upgraded to 3 so thought I woudl give it a go ... but (aint > there always one of those :() can't seem to add the principle .. > > kadmin.local: add_principal krbtgt/OLD-REALM at IPA-REALM > WARNING: no policy specified for krbtgt/OLD-REALM at IPA-REALM; defaulting > to no policy > Enter password for principal "krbtgt/OLD-REALM at IPA-REALM": > Re-enter password for principal "krbtgt/OLD-REALM at IPA-REALM": > add_principal: Invalid argument while creating "krbtgt/OLD-REALM at IPA-REALM". > > and nothing was placed in the kadmin log .. :( This is almost certainly a bug, can you open a ticket so we can investigate ? Simo. -- Simo Sorce * Red Hat, Inc * New York From erinn.looneytriggs at gmail.com Wed Nov 27 18:21:52 2013 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Wed, 27 Nov 2013 11:21:52 -0700 Subject: [Freeipa-users] CA expiration and renewal In-Reply-To: <52939269.1070405@redhat.com> References: <52842407.80504@gmail.com> <52939269.1070405@redhat.com> Message-ID: <52963840.8090703@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/25/2013 11:09 AM, Rob Crittenden wrote: > Erinn Looney-Triggs wrote: >> Folks just wanted to touch base again before the American holiday >> season starts. My CA, which is subordinate to AD CS will be >> expiring on December 9th, I submitted a bug, y'all drew up docs >> etc for a plan (thanks). Now I just wanted to see how it was >> going and if need be what manual steps I will need to take to >> renew the certificate. >> >> Thanks again for the great work, > > We're working on an a set of tools to make this easier. For now > I've appended some manual instructions onto a page still in > progress. > > http://www.freeipa.org/page/Howto/CA_Certificate_Renewal#Manual_Procedure_in_IPA_3.0 > > > > Some parts may be still be a little rough or hard to understand. > Let me know if you have any problems or corrections. > > rob Rob, Thanks for the instructions, a few questions. What sort of interruption in service could this create? Can you expand on this section a little bit: Replace the value of ca.signing.cert in /etc/pki-ca/CS.cfg. This is the base64 value of the certificate. You can obtain this by removing the BEGIN/END blocks from ipa.crt and compressing it into a single line. Thanks and happy Thanksgiving, - -Erinn -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) iQEcBAEBAgAGBQJSljg7AAoJENetaK3v/E7P9EsIAI6u6A2702kCFqz0j+DDnz0v vaLra+syW8yxvEXFquHInVnXLWXbdtx0NYks0I+WFzYQGhIp9kM2GCpGTGcQYw3y Hi+dCNbEmKyJzA+gWdswDIMmvWVfOR9jc5D7L5gRXU4/bb7osECBSvUhNt6Jd2Jw ejKzE9yRNn9KU0RFGfOeq81fdoAl8GYKJiqeL1V0ATpGZepfhwMyQdbEsGPcrbwM cKm9WQRfWwurkFBXFO4BJxELgS4/WxraWWb7JA+sjCrctRVvl2odloHgGYanfT0z c33dNJDkneXvKvw0E1y62NVupI4z5XRHqad5PepWkUKI9n12c/YC8hUZQ3aspto= =uDkT -----END PGP SIGNATURE----- From rcritten at redhat.com Wed Nov 27 19:11:47 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 27 Nov 2013 14:11:47 -0500 Subject: [Freeipa-users] CA expiration and renewal In-Reply-To: <52963840.8090703@gmail.com> References: <52842407.80504@gmail.com> <52939269.1070405@redhat.com> <52963840.8090703@gmail.com> Message-ID: <529643F3.9020907@redhat.com> Erinn Looney-Triggs wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > On 11/25/2013 11:09 AM, Rob Crittenden wrote: >> Erinn Looney-Triggs wrote: >>> Folks just wanted to touch base again before the American holiday >>> season starts. My CA, which is subordinate to AD CS will be >>> expiring on December 9th, I submitted a bug, y'all drew up docs >>> etc for a plan (thanks). Now I just wanted to see how it was >>> going and if need be what manual steps I will need to take to >>> renew the certificate. >>> >>> Thanks again for the great work, >> >> We're working on an a set of tools to make this easier. For now >> I've appended some manual instructions onto a page still in >> progress. >> >> http://www.freeipa.org/page/Howto/CA_Certificate_Renewal#Manual_Procedure_in_IPA_3.0 >> >> >> >> Some parts may be still be a little rough or hard to understand. >> Let me know if you have any problems or corrections. >> >> rob > > Rob, > > Thanks for the instructions, a few questions. > > What sort of interruption in service could this create? Services will be restarted during this process including your LDAP, Apache and CA instances. Downtime should be relatively short, no more than a few minutes combined. > Can you expand on this section a little bit: > Replace the value of ca.signing.cert in /etc/pki-ca/CS.cfg. This is > the base64 value of the certificate. You can obtain this by removing > the BEGIN/END blocks from ipa.crt and compressing it into a single line. A PEM cert looks like: -----BEGIN CERTIFICATE----- MIIB/zCCAWigAwIBAgICA+gwDQYJKoZIhvcNAQEFBQAwKTEnMCUGA1UEAxMeSVBB IFRlc3QgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTEwMDIyMzIyMzMxNVoXDTIw MDIyMzIyMzMxNVowKTEnMCUGA1UEAxMeSVBBIFRlc3QgQ2VydGlmaWNhdGUgQXV0 aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+G6ultyLaXqzBlypA DnOsinkMTlZZssTFQh/QUMi1F1fcn8QUlmsl9a+l6w6hfZm7P8z3sVwsjLQcDWA4 KxOh+LmIsNL4OKx4wKF1q/pSt1PATRU5Pgu2+3wlwJO0H7cl4QfavoOLwmxAZf/l ZNIy/5czvSWFWj7EJj16ty9BeQIDAQABozYwNDARBglghkgBhvhCAQEEBAMCAAcw DwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAsQwDQYJKoZIhvcNAQEFBQAD gYEAl0gIshwNkhyfNe1XMLswPeOgH5YN1BUuKXzbv1fuSIkArjwLODr4cOdXzQvt yaiX6Z+pRC/sK8MgLhPxV2X9QVQdzKfLkVGIdboCt1j3EXxSUCZeIuSKouitkWYe eSH9DQkYDp/oKgANLWnY7CNorPz6xQktp1pB0DGohV1BeTA= -----END CERTIFICATE----- You need to drop the BEGIN/END blocks then combine all the lines into a single line, so you have a unified base64 blog. It will look like: ca.signing.cert=MII...B0DGohV1BeTA= I was afraid wrapping woudl destroy my demonstration so I used ellipses instead. > Thanks and happy Thanksgiving, You're welcome. You too. rob From matthew.bryant at melbourneit.com.au Wed Nov 27 22:29:33 2013 From: matthew.bryant at melbourneit.com.au (Matt Bryant) Date: Thu, 28 Nov 2013 08:29:33 +1000 Subject: [Freeipa-users] Trust between IPA and another MIT Kerberos Realm In-Reply-To: <1385557516.22025.80.camel@willson.li.ssimo.org> References: <529549D4.6020001@melbourneit.com.au> <52956D92.3030606@redhat.com> <52958221.4030809@melbourneit.com.au> <1385557516.22025.80.camel@willson.li.ssimo.org> Message-ID: <5296724D.1040206@melbourneit.com.au> Simo, Have added the following into bugzilla .. Bug 1035494 has been added to the database seems strange but whilst listprincs/getprinc works getpols and the addprinc (at least in this use case) doesnt... ie kadmin.local: add_principal -pw XXXXXXX krbtgt/OLD-REALM at IPA-REALM WARNING: no policy specified for krbtgt/OLD-REALM at IPA-REALM; defaulting to no policy add_principal: Invalid argument while creating "krbtgt/OLD-REALM at IPA-REALM". kadmin.local: listpols get_policies: Plugin does not support the operation while retrieving list. rgds Matt B. On 11/27/2013 11:05 PM, Simo Sorce wrote: > On Wed, 2013-11-27 at 15:24 +1000, Matt Bryant wrote: >> Hmm just upgraded to 3 so thought I woudl give it a go ... but (aint >> there always one of those :() can't seem to add the principle .. >> >> kadmin.local: add_principal krbtgt/OLD-REALM at IPA-REALM >> WARNING: no policy specified for krbtgt/OLD-REALM at IPA-REALM; defaulting >> to no policy >> Enter password for principal "krbtgt/OLD-REALM at IPA-REALM": >> Re-enter password for principal "krbtgt/OLD-REALM at IPA-REALM": >> add_principal: Invalid argument while creating "krbtgt/OLD-REALM at IPA-REALM". >> >> and nothing was placed in the kadmin log .. :( > This is almost certainly a bug, can you open a ticket so we can > investigate ? > > Simo. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Wed Nov 27 23:10:20 2013 From: simo at redhat.com (Simo Sorce) Date: Wed, 27 Nov 2013 18:10:20 -0500 Subject: [Freeipa-users] Trust between IPA and another MIT Kerberos Realm In-Reply-To: <5296724D.1040206@melbourneit.com.au> References: <529549D4.6020001@melbourneit.com.au> <52956D92.3030606@redhat.com> <52958221.4030809@melbourneit.com.au> <1385557516.22025.80.camel@willson.li.ssimo.org> <5296724D.1040206@melbourneit.com.au> Message-ID: <1385593820.14987.29.camel@willson.li.ssimo.org> On Thu, 2013-11-28 at 08:29 +1000, Matt Bryant wrote: > Simo, > > Have added the following into bugzilla .. > > Bug 1035494 has been added to the database > > seems strange but whilst listprincs/getprinc works getpols and the > addprinc (at least in this use case) doesnt... addprinc not working for normal user principals is expected, we block it to prevent the creation of incomplete user accounts. I think getpols is also expected to fail as we use IPA specific policies. However it should allow you to create krbtgt/OLD-REALM at IPA-REALM to set up trusts until we provide an explicit command for it. This is why I wanted you to open a bug on that. > ie > kadmin.local: add_principal -pw XXXXXXX krbtgt/OLD-REALM at IPA-REALM > WARNING: no policy specified for krbtgt/OLD-REALM at IPA-REALM; > defaulting to no policy > add_principal: Invalid argument while creating > "krbtgt/OLD-REALM at IPA-REALM". Now that I think of it, there is an undocumented switch that will allow you to create an arbitrary principal. This switch should NEVER be used to create user principals or normal host principals, however it should allow you to workaround the issue until we can fix the kadmin interface. Use kadmin.local -x ipa-setup-override-restrictions But please use it exclusively to create the krbtgt/REALM1 at REALM2 principals and nothing else. Simo. -- Simo Sorce * Red Hat, Inc * New York From matthew.bryant at melbourneit.com.au Wed Nov 27 23:48:19 2013 From: matthew.bryant at melbourneit.com.au (Matt Bryant) Date: Thu, 28 Nov 2013 09:48:19 +1000 Subject: [Freeipa-users] Trust between IPA and another MIT Kerberos Realm In-Reply-To: <1385593820.14987.29.camel@willson.li.ssimo.org> References: <529549D4.6020001@melbourneit.com.au> <52956D92.3030606@redhat.com> <52958221.4030809@melbourneit.com.au> <1385557516.22025.80.camel@willson.li.ssimo.org> <5296724D.1040206@melbourneit.com.au> <1385593820.14987.29.camel@willson.li.ssimo.org> Message-ID: <529684C3.4090100@melbourneit.com.au> Simo, Thanks for that .. using that switch the principle is now created on to see it it works as expected .. rgds Matt B. On 11/28/2013 09:10 AM, Simo Sorce wrote: > On Thu, 2013-11-28 at 08:29 +1000, Matt Bryant wrote: >> Simo, >> >> Have added the following into bugzilla .. >> >> Bug 1035494 has been added to the database >> >> seems strange but whilst listprincs/getprinc works getpols and the >> addprinc (at least in this use case) doesnt... > addprinc not working for normal user principals is expected, we block it > to prevent the creation of incomplete user accounts. > > I think getpols is also expected to fail as we use IPA specific > policies. > > However it should allow you to create krbtgt/OLD-REALM at IPA-REALM to set > up trusts until we provide an explicit command for it. This is why I > wanted you to open a bug on that. > >> ie >> kadmin.local: add_principal -pw XXXXXXX krbtgt/OLD-REALM at IPA-REALM >> WARNING: no policy specified for krbtgt/OLD-REALM at IPA-REALM; >> defaulting to no policy >> add_principal: Invalid argument while creating >> "krbtgt/OLD-REALM at IPA-REALM". > Now that I think of it, there is an undocumented switch that will allow > you to create an arbitrary principal. This switch should NEVER be used > to create user principals or normal host principals, however it should > allow you to workaround the issue until we can fix the kadmin interface. > > Use kadmin.local -x ipa-setup-override-restrictions > > But please use it exclusively to create the krbtgt/REALM1 at REALM2 > principals and nothing else. > > Simo. > From Steven.Jones at vuw.ac.nz Thu Nov 28 00:19:15 2013 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Thu, 28 Nov 2013 00:19:15 +0000 Subject: [Freeipa-users] winsyncs - multiple Message-ID: <833D8E48405E064EBC54C84EC6B36E407FB7271F@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, I currently have a winsync agreement from one AD domain to one of three IPA servers, works fine. Can I set up another winsync agreement from a different AD to one of the other IPA servers and one way sync that as well? The obvious risk is a user id clash, but both domains have different naming policy. So can this be done? regards Steven Jones Technical Specialist - Linux RHCE Victoria University ITS, Level 8 Rankin Brown Building, Wellington, NZ 6012 0064 4 463 6272 ________________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Matt Bryant [matthew.bryant at melbourneit.com.au] Sent: Thursday, 28 November 2013 12:48 p.m. Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Trust between IPA and another MIT Kerberos Realm Simo, Thanks for that .. using that switch the principle is now created on to see it it works as expected .. rgds Matt B. On 11/28/2013 09:10 AM, Simo Sorce wrote: > On Thu, 2013-11-28 at 08:29 +1000, Matt Bryant wrote: >> Simo, >> >> Have added the following into bugzilla .. >> >> Bug 1035494 has been added to the database >> >> seems strange but whilst listprincs/getprinc works getpols and the >> addprinc (at least in this use case) doesnt... > addprinc not working for normal user principals is expected, we block it > to prevent the creation of incomplete user accounts. > > I think getpols is also expected to fail as we use IPA specific > policies. > > However it should allow you to create krbtgt/OLD-REALM at IPA-REALM to set > up trusts until we provide an explicit command for it. This is why I > wanted you to open a bug on that. > >> ie >> kadmin.local: add_principal -pw XXXXXXX krbtgt/OLD-REALM at IPA-REALM >> WARNING: no policy specified for krbtgt/OLD-REALM at IPA-REALM; >> defaulting to no policy >> add_principal: Invalid argument while creating >> "krbtgt/OLD-REALM at IPA-REALM". > Now that I think of it, there is an undocumented switch that will allow > you to create an arbitrary principal. This switch should NEVER be used > to create user principals or normal host principals, however it should > allow you to workaround the issue until we can fix the kadmin interface. > > Use kadmin.local -x ipa-setup-override-restrictions > > But please use it exclusively to create the krbtgt/REALM1 at REALM2 > principals and nothing else. > > Simo. > _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users From erinn.looneytriggs at gmail.com Thu Nov 28 22:50:58 2013 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Thu, 28 Nov 2013 15:50:58 -0700 Subject: [Freeipa-users] Dogtag not working? Message-ID: <5297C8D2.4080407@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In the process of prepping a replication host for changing over the CA I had to use certmonger to generate another certificate on my secondary IPA server. Unfortunately it seems to fail every single time. Here is what I am running and here is what I am getting: ipa-getcert request -k private/ipa2.abaqis.com.key -f certs/ipa2.abaqis.com.crt -g 2048 The request appears to work, however when checking the list I receive the following: ipa-getcert list -r Number of certificates and requests being tracked: 9. Request ID '20131128202128': status: CA_UNREACHABLE ca-error: Server failed request, will retry: 4301 (RPC failed at server. Certificate operation cannot be completed: FAILURE (Authentication Error)). stuck: yes key pair storage: type=FILE,location='/etc/pki/tls/private/ipa2.abaqis.com.key' certificate: type=FILE,location='/etc/pki/tls/certs/ipa2.abaqis.com.crt' CA: IPA issuer: subject: expires: unknown pre-save command: post-save command: track: yes auto-renew: yes Fine, I check the http logs and get about the same: [Thu Nov 28 22:03:06 2013] [error] ipa: ERROR: ipaserver.plugins.dogtag.ra.request_certificate(): FAILURE (Authentication Error) Now as I understand it ipa-getcert is going to theserver listed in /etc/ipa/default.conf, which in this case is ipa2.abaqis.com (the request is coming from the same host). The host principle in /etc/krb5.keytab is used for authentication. I have tested against the primary ipa server and everything works as it should. However, any requests going against ipa2 for certificates are failing. At this point I am stuck, so any suggestions are welcome. - -Erinn -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) iQEcBAEBAgAGBQJSl8jOAAoJENetaK3v/E7Pzr0IAJ78nYZRDAVzKCuzceWR+qdf sB0VoOyJDPNOOKoQixOhTl01zDPqfIeR7tZBWVpDkg09/KV9HD2J4A5QRfAQHn7F wISncthoLK5DgtLD1FDlvrVIqV7iRjGva8YDnp0lDRYtASUBignrnHez9t+LGdet dJmLkpduyufcwZJWaVi1S4SMqjpsAbJGZK3b6D6PO5pe/bVvxuZq6bU+TxF7Jxy/ cnFV0OG7Mhi0O25p0JVMO5j47Wv5KiJRznzlEP3OpsZkNw7x8SzGdrx/1FpsR+OJ emDP1Cwc1fJfb/pYwXQcNI3dtkMANnrDOlhx7yJbUviHhPFhLz8PF6KSym7nwsU= =tMYx -----END PGP SIGNATURE----- From dpal at redhat.com Fri Nov 29 07:29:10 2013 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 29 Nov 2013 02:29:10 -0500 Subject: [Freeipa-users] winsyncs - multiple In-Reply-To: <833D8E48405E064EBC54C84EC6B36E407FB7271F@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E407FB7271F@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <52984246.10402@redhat.com> On 11/27/2013 07:19 PM, Steven Jones wrote: > Hi, > > I currently have a winsync agreement from one AD domain to one of three IPA servers, works fine. > > Can I set up another winsync agreement from a different AD to one of the other IPA servers and one way sync that as well? > > The obvious risk is a user id clash, but both domains have different naming policy. You are on the right path to answer to your own question. ;-) Yes this can be done and "might" work but since software can't guarantee uniqueness it is discouraged. If the naming policy is not that "clean" you might end up with an inconsistent behavior that is had to troubleshoot. > > So can this be done? > > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University ITS, > > Level 8 Rankin Brown Building, > > Wellington, NZ > > 6012 > > 0064 4 463 6272 > > ________________________________________ > From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Matt Bryant [matthew.bryant at melbourneit.com.au] > Sent: Thursday, 28 November 2013 12:48 p.m. > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Trust between IPA and another MIT Kerberos Realm > > Simo, > > Thanks for that .. using that switch the principle is now created on to > see it it works as expected .. > > rgds > > Matt B. > > On 11/28/2013 09:10 AM, Simo Sorce wrote: >> On Thu, 2013-11-28 at 08:29 +1000, Matt Bryant wrote: >>> Simo, >>> >>> Have added the following into bugzilla .. >>> >>> Bug 1035494 has been added to the database >>> >>> seems strange but whilst listprincs/getprinc works getpols and the >>> addprinc (at least in this use case) doesnt... >> addprinc not working for normal user principals is expected, we block it >> to prevent the creation of incomplete user accounts. >> >> I think getpols is also expected to fail as we use IPA specific >> policies. >> >> However it should allow you to create krbtgt/OLD-REALM at IPA-REALM to set >> up trusts until we provide an explicit command for it. This is why I >> wanted you to open a bug on that. >> >>> ie >>> kadmin.local: add_principal -pw XXXXXXX krbtgt/OLD-REALM at IPA-REALM >>> WARNING: no policy specified for krbtgt/OLD-REALM at IPA-REALM; >>> defaulting to no policy >>> add_principal: Invalid argument while creating >>> "krbtgt/OLD-REALM at IPA-REALM". >> Now that I think of it, there is an undocumented switch that will allow >> you to create an arbitrary principal. This switch should NEVER be used >> to create user principals or normal host principals, however it should >> allow you to workaround the issue until we can fix the kadmin interface. >> >> Use kadmin.local -x ipa-setup-override-restrictions >> >> But please use it exclusively to create the krbtgt/REALM1 at REALM2 >> principals and nothing else. >> >> Simo. >> > _______________________________________________ > 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 Less at imagine-sw.com Fri Nov 29 08:16:20 2013 From: Less at imagine-sw.com (Les Stott) Date: Fri, 29 Nov 2013 08:16:20 +0000 Subject: [Freeipa-users] gssapi sasl error - only picking up short hostname when running ipa-client-install (and failing) Message-ID: <4ED173A868981548967B4FCA2707222601E1BD@AACMBXP04.exchserver.com> Hi, Recently installed freeipa on two servers in multi-master mode. We want to have a central authentication system for many hosts. Environment is RHEL 6.4 for servers, RHEL 6.1 for the first client host, standard rpm packages used - ipa-server-3.0.0-26.el6_4.4.x86_64 and ipa-client-3.0.0-37.el6.x86_64. I am now trying to add the first linux host to freeipa via ipa-client-install. When I run ipa-client-install on a host in debug mode it fails with errors below (I have changed hostnames and ip's, freeipa-1.mydomain.com 192.168.1.22 and freeipa-2.mydomain.com 192.168.1.23, host client - host1 192.168.1.15) trying to retrieve CA cert via LDAP from ldap://freeipa-1.mydomain.com get_ca_cert_from_ldap() error: Local error SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Server ldap/freeipa-1 at MYDOMAIN.COM not found in Kerberos database) {'info': 'SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Server ldap/freeipa-1 at MYDOMAIN.COM not found in Kerberos database)', 'desc': 'Local error'} The Kerberos logs on the server (free-ipa-1) show Nov 29 01:46:14 freeipa-1.mydomain.com krb5kdc[1616](info): TGS_REQ (4 etypes {18 17 16 23}) 192.168.1.15: UNKNOWN_SERVER: authtime 0, admin@ MYDOMAIN.COM for HTTP/ freeipa-1 at MYDOMAIN.COM, Server not found in Kerberos database The logs indicate that the service name is being used with the short hostname (HTTP/ freeipa-1 at MYDOMAIN.COM). The FreeIPA server has records for HTTP/ freeipa-1.mydomain.com at MYDOMAIN.COM. I can see these in the web interface. I believe this is where it is stumbling. I've been banging my head against the wall on this one for a couple of days. Everything I've found says make sure you have working dns, make sure you can reverse lookup ip's, make sure hostnames are fqdn, make sure /etc/hosts on server has ip's for servers listed with fqdn first and shortname second. I've done all that. I am using external dns (not integrated with freeipa), and have populated all records required as per sample config files provided during install. My time servers are other servers too, but that shouldn't matter, everything is in sync. ; for Kerberos Auto Discovery ; ldap servers _ldap._tcp IN SRV 0 100 389 freeipa-1.mydomain.com. _ldap._tcp IN SRV 0 100 389 freeipa-2.mydomain.com. ;kerberos realm _kerberos IN TXT MYDOMAIN.COM ; kerberos servers _kerberos._tcp IN SRV 0 100 88 freeipa-1.mydomain.com. _kerberos._tcp IN SRV 0 100 88 freeipa-2.mydomain.com. _kerberos._udp IN SRV 0 100 88 freeipa-1.mydomain.com. _kerberos._ucp IN SRV 0 100 88 freeipa-2.mydomain.com. _kerberos-master._tcp IN SRV 0 100 88 freeipa-1.mydomain.com. _kerberos-master._tcp IN SRV 0 100 88 freeipa-2.mydomain.com. _kerberos-master._udp IN SRV 0 100 88 freeipa-1.mydomain.com. _kerberos-master._udp IN SRV 0 100 88 freeipa-2.mydomain.com. _kpasswd._tcp IN SRV 0 100 464 freeipa-1.mydomain.com. _kpasswd._tcp IN SRV 0 100 464 freeipa-2.mydomain.com. _kpasswd._udp IN SRV 0 100 464 freeipa-1.mydomain.com. _kpasswd._udp IN SRV 0 100 464 freeipa-2.mydomain.com. ;ntp server _ntp._udp IN SRV 0 100 123 ntp1.mydomain.com. _ntp._udp IN SRV 0 100 123 ntp2.mydomain.com. Reverse dns entries are also available and both freeipa servers and the host I am trying to configure ipa-client on can do lookups and receive fqdn's. They can all do reverse lookups that resolve correctly. I have read that when using SASL/GSSAPI (Kerberos) authentication, its possible that the service provider sets the principal name (SPN) to "ldap/servername" in the TGS_REQ based on a dns query of the PTR record. I do have PTR's configured, and they have FQDN's. Is it true that this happens with GSSAPI? If so how can I get around that? Reverse Zone File for 192.168.1 22 PTR freeipa-1.mydomain.com. 23 PTR freeipa-2.mydomain.com. Nslookup results for each IP: 22.1.168.192.in-addr.arpa name = freeipa-1.mydomain.com. 23.1.168.192.in-addr.arpa name = freeipa-2.mydomain.com. I can authenticate using kinit before running the script and it still doesn't work. The short version of running the install shows: Discovery was successful! Hostname: host1.mydomain.com Realm: MYDOMAIN.COM DNS Domain: mydomain.com IPA Server: freeipa-1.mydomain.com BaseDN: dc=mydomain,dc=com It authenticates correctly with the admin user for enrolling the host, but joining the realm fails. I've tried everything I can think of. Please help. Thanks, Les -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Fri Nov 29 09:49:44 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 29 Nov 2013 10:49:44 +0100 Subject: [Freeipa-users] gssapi sasl error - only picking up short hostname when running ipa-client-install (and failing) In-Reply-To: <4ED173A868981548967B4FCA2707222601E1BD@AACMBXP04.exchserver.com> References: <4ED173A868981548967B4FCA2707222601E1BD@AACMBXP04.exchserver.com> Message-ID: <52986338.4000106@redhat.com> On 11/29/2013 09:16 AM, Les Stott wrote: > Hi, > > Recently installed freeipa on two servers in multi-master mode. We want to have a central authentication system for many hosts. Environment is RHEL 6.4 for servers, RHEL 6.1 for the first client host, standard rpm packages used - ipa-server-3.0.0-26.el6_4.4.x86_64 and ipa-client-3.0.0-37.el6.x86_64. > > I am now trying to add the first linux host to freeipa via ipa-client-install. > > When I run ipa-client-install on a host in debug mode it fails with errors below (I have changed hostnames and ip's, freeipa-1.mydomain.com 192.168.1.22 and freeipa-2.mydomain.com 192.168.1.23, host client - host1 192.168.1.15) > > trying to retrieve CA cert via LDAP from ldap://freeipa-1.mydomain.com > get_ca_cert_from_ldap() error: Local error SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Server ldap/freeipa-1 at MYDOMAIN.COM not found in Kerberos database) > {'info': 'SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Server ldap/freeipa-1 at MYDOMAIN.COM not found in Kerberos database)', 'desc': 'Local error'} > > The Kerberos logs on the server (free-ipa-1) show > Nov 29 01:46:14 freeipa-1.mydomain.com krb5kdc[1616](info): TGS_REQ (4 etypes {18 17 16 23}) 192.168.1.15: UNKNOWN_SERVER: authtime 0, admin@ MYDOMAIN.COM for HTTP/ freeipa-1 at MYDOMAIN.COM, Server not found in Kerberos database > > The logs indicate that the service name is being used with the short hostname (HTTP/ freeipa-1 at MYDOMAIN.COM). The FreeIPA server has records for HTTP/ freeipa-1.mydomain.com at MYDOMAIN.COM. I can see these in the web interface. I believe this is where it is stumbling. > > I've been banging my head against the wall on this one for a couple of days. Everything I've found says make sure you have working dns, make sure you can reverse lookup ip's, make sure hostnames are fqdn, make sure /etc/hosts on server has ip's for servers listed with fqdn first and shortname second. I've done all that. What about /etc/hosts on the clients? Do they also have FQDN first in case they have server IP in there? Martin From natxo.asenjo at gmail.com Fri Nov 29 10:27:36 2013 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Fri, 29 Nov 2013 11:27:36 +0100 Subject: [Freeipa-users] postfix ipa Message-ID: hi, just came accross Erinn Looney-Triggs's excellent writeup on using kerberos voor relaying e-mail (https://stomp.colorado.edu/blog/blog/2013/07/09/on-freeipa-postfix-and-a-relaying-smtp-client/) and have a question. Would it not be possibly easier to just use the host's keytab (/etc/krb5.keytab) instead of just deploying a new service principal to every smtp client? I ask this because I am in the point of deploying something similar and would rather not need to have to deploy another set of keytabs everywhere unless this is a security malpractice, of course. TIA, -- Groeten, natxo From mkosek at redhat.com Fri Nov 29 11:03:58 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 29 Nov 2013 12:03:58 +0100 Subject: [Freeipa-users] postfix ipa In-Reply-To: References: Message-ID: <5298749E.9070207@redhat.com> On 11/29/2013 11:27 AM, Natxo Asenjo wrote: > hi, > > just came accross Erinn Looney-Triggs's excellent writeup on using > kerberos voor relaying e-mail > (https://stomp.colorado.edu/blog/blog/2013/07/09/on-freeipa-postfix-and-a-relaying-smtp-client/) > and have a question. > > Would it not be possibly easier to just use the host's keytab > (/etc/krb5.keytab) instead of just deploying a new service principal > to every smtp client? > > I ask this because I am in the point of deploying something similar > and would rather not need to have to deploy another set of keytabs > everywhere unless this is a security malpractice, of course. > > TIA, > -- > Groeten, > natxo Easier? Yes. More secure? Probably not. Kerberos experts may correct me, but from my POV, it is better to separate these privileges. It postfix works on host/`hostname`@REALM, it could act as a host identity. For example, attacker could change host's SSH public keys in FreeIPA host entry in LDAP if it takes control over the mail service. Or it could unenroll the host entirely from FreeIPA. If it run's on own keytab and thus an own identity, it can only act on behalf it. Martin From sbose at redhat.com Fri Nov 29 11:22:58 2013 From: sbose at redhat.com (Sumit Bose) Date: Fri, 29 Nov 2013 12:22:58 +0100 Subject: [Freeipa-users] postfix ipa In-Reply-To: <5298749E.9070207@redhat.com> References: <5298749E.9070207@redhat.com> Message-ID: <20131129112258.GY3414@localhost.localdomain> On Fri, Nov 29, 2013 at 12:03:58PM +0100, Martin Kosek wrote: > On 11/29/2013 11:27 AM, Natxo Asenjo wrote: > > hi, > > > > just came accross Erinn Looney-Triggs's excellent writeup on using > > kerberos voor relaying e-mail > > (https://stomp.colorado.edu/blog/blog/2013/07/09/on-freeipa-postfix-and-a-relaying-smtp-client/) > > and have a question. > > > > Would it not be possibly easier to just use the host's keytab > > (/etc/krb5.keytab) instead of just deploying a new service principal > > to every smtp client? > > > > I ask this because I am in the point of deploying something similar > > and would rather not need to have to deploy another set of keytabs > > everywhere unless this is a security malpractice, of course. > > > > TIA, > > -- > > Groeten, > > natxo > > Easier? Yes. More secure? Probably not. > > Kerberos experts may correct me, but from my POV, it is better to separate > these privileges. It postfix works on host/`hostname`@REALM, it could act as a > host identity. For example, attacker could change host's SSH public keys in > FreeIPA host entry in LDAP if it takes control over the mail service. Or it > could unenroll the host entirely from FreeIPA. > > If it run's on own keytab and thus an own identity, it can only act on behalf it. yes, reusing keytabs is like giving all users the same password and making them aware of it. bye, Sumit > > Martin > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From fvzwieten at vxcompany.com Fri Nov 29 12:53:40 2013 From: fvzwieten at vxcompany.com (Fred van Zwieten) Date: Fri, 29 Nov 2013 13:53:40 +0100 Subject: [Freeipa-users] local root can su to any IPA user Message-ID: Hi, When being root on an ipa-client, I can su to any IPA user. This is somewhat unexptected behaviour in comparison to Windows. If I am local administrator in a windows AD member server, I cannot become a domain user. I need to be domain administrator for that. Is it possible to have this "feature" disabled somehow? Fred -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Fri Nov 29 13:11:01 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 29 Nov 2013 15:11:01 +0200 Subject: [Freeipa-users] local root can su to any IPA user In-Reply-To: References: Message-ID: <20131129131101.GV21264@redhat.com> On Fri, 29 Nov 2013, Fred van Zwieten wrote: >Hi, > >When being root on an ipa-client, I can su to any IPA user. This is >somewhat unexptected behaviour in comparison to Windows. If I am local >administrator in a windows AD member server, I cannot become a domain user. >I need to be domain administrator for that. > >Is it possible to have this "feature" disabled somehow? root user on Linux systems by default has CAP_SETUID capability which allows to change process uid to a different user. If the capability is there, the only way to reduce transition from a specific user to another one is by confining it via appropriate security module, for example, through properly defined SELinux policy that prevents a root to transition to the context of an IPA user. Someone needs to write this policy and deploy at IPA clients first. -- / Alexander Bokovoy From Less at imagine-sw.com Fri Nov 29 13:20:19 2013 From: Less at imagine-sw.com (Les Stott) Date: Fri, 29 Nov 2013 13:20:19 +0000 Subject: [Freeipa-users] gssapi sasl error - only picking up short hostname when running ipa-client-install (and failing) In-Reply-To: <52986338.4000106@redhat.com> References: <4ED173A868981548967B4FCA2707222601E1BD@AACMBXP04.exchserver.com>, <52986338.4000106@redhat.com> Message-ID: <4ED173A868981548967B4FCA2707222601E521@AACMBXP04.exchserver.com> Martin, there is no entries in /etc/hosts for the freeipa servers on the client. the clients hosts own entry is there with fqdn first. Because you mentioned it, i added the hostname of both freeipa server to the hosts file on the client. It actually ran and setup the client. However it did get the following errors at the end after it did kerberos config.... ======= Configured /etc/krb5.conf for IPA realm MYDOMAIN.COM Traceback (most recent call last): File "/usr/sbin/ipa-client-install", line 2377, in sys.exit(main()) File "/usr/sbin/ipa-client-install", line 2363, in main rval = install(options, env, fstore, statestore) File "/usr/sbin/ipa-client-install", line 2135, in install delete_persistent_client_session_data(host_principal) File "/usr/lib/python2.6/site-packages/ipalib/rpc.py", line 124, in delete_persistent_client_session_data kernel_keyring.del_key(keyname) File "/usr/lib/python2.6/site-packages/ipapython/kernel_keyring.py", line 99, in del_key real_key = get_real_key(key) File "/usr/lib/python2.6/site-packages/ipapython/kernel_keyring.py", line 45, in get_real_key (stdout, stderr, rc) = run(['keyctl', 'search', KEYRING, KEYTYPE, key], raiseonerr=False) File "/usr/lib/python2.6/site-packages/ipapython/ipautil.py", line 295, in run close_fds=True, env=env, cwd=cwd) File "/usr/lib64/python2.6/subprocess.py", line 639, in __init__ errread, errwrite) File "/usr/lib64/python2.6/subprocess.py", line 1220, in _execute_child raise child_exception OSError: [Errno 2] No such file or directory ======= Is that normal? Do i need to add entries to the hosts file on every client? Regards, Les ________________________________________ From: Martin Kosek [mkosek at redhat.com] Sent: Friday, November 29, 2013 8:49 PM To: Les Stott; freeipa-users at redhat.com Subject: Re: [Freeipa-users] gssapi sasl error - only picking up short hostname when running ipa-client-install (and failing) On 11/29/2013 09:16 AM, Les Stott wrote: > Hi, > > Recently installed freeipa on two servers in multi-master mode. We want to have a central authentication system for many hosts. Environment is RHEL 6.4 for servers, RHEL 6.1 for the first client host, standard rpm packages used - ipa-server-3.0.0-26.el6_4.4.x86_64 and ipa-client-3.0.0-37.el6.x86_64. > > I am now trying to add the first linux host to freeipa via ipa-client-install. > > When I run ipa-client-install on a host in debug mode it fails with errors below (I have changed hostnames and ip's, freeipa-1.mydomain.com 192.168.1.22 and freeipa-2.mydomain.com 192.168.1.23, host client - host1 192.168.1.15) > > trying to retrieve CA cert via LDAP from ldap://freeipa-1.mydomain.com > get_ca_cert_from_ldap() error: Local error SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Server ldap/freeipa-1 at MYDOMAIN.COM not found in Kerberos database) > {'info': 'SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Server ldap/freeipa-1 at MYDOMAIN.COM not found in Kerberos database)', 'desc': 'Local error'} > > The Kerberos logs on the server (free-ipa-1) show > Nov 29 01:46:14 freeipa-1.mydomain.com krb5kdc[1616](info): TGS_REQ (4 etypes {18 17 16 23}) 192.168.1.15: UNKNOWN_SERVER: authtime 0, admin@ MYDOMAIN.COM for HTTP/ freeipa-1 at MYDOMAIN.COM, Server not found in Kerberos database > > The logs indicate that the service name is being used with the short hostname (HTTP/ freeipa-1 at MYDOMAIN.COM). The FreeIPA server has records for HTTP/ freeipa-1.mydomain.com at MYDOMAIN.COM. I can see these in the web interface. I believe this is where it is stumbling. > > I've been banging my head against the wall on this one for a couple of days. Everything I've found says make sure you have working dns, make sure you can reverse lookup ip's, make sure hostnames are fqdn, make sure /etc/hosts on server has ip's for servers listed with fqdn first and shortname second. I've done all that. What about /etc/hosts on the clients? Do they also have FQDN first in case they have server IP in there? Martin From pspacek at redhat.com Fri Nov 29 13:28:39 2013 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 29 Nov 2013 14:28:39 +0100 Subject: [Freeipa-users] gssapi sasl error - only picking up short hostname when running ipa-client-install (and failing) In-Reply-To: <4ED173A868981548967B4FCA2707222601E521@AACMBXP04.exchserver.com> References: <4ED173A868981548967B4FCA2707222601E1BD@AACMBXP04.exchserver.com>, <52986338.4000106@redhat.com> <4ED173A868981548967B4FCA2707222601E521@AACMBXP04.exchserver.com> Message-ID: <52989687.30009@redhat.com> On 29.11.2013 14:20, Les Stott wrote: > Martin, > > there is no entries in /etc/hosts for the freeipa servers on the client. > the clients hosts own entry is there with fqdn first. > > Because you mentioned it, i added the hostname of both freeipa server to the hosts file on the client. It actually ran and setup the client. However it did get the following errors at the end after it did kerberos config.... > > ======= > Configured /etc/krb5.conf for IPA realm MYDOMAIN.COM > Traceback (most recent call last): > File "/usr/sbin/ipa-client-install", line 2377, in > sys.exit(main()) > File "/usr/sbin/ipa-client-install", line 2363, in main > rval = install(options, env, fstore, statestore) > File "/usr/sbin/ipa-client-install", line 2135, in install > delete_persistent_client_session_data(host_principal) > File "/usr/lib/python2.6/site-packages/ipalib/rpc.py", line 124, in delete_persistent_client_session_data > kernel_keyring.del_key(keyname) > File "/usr/lib/python2.6/site-packages/ipapython/kernel_keyring.py", line 99, in del_key > real_key = get_real_key(key) > File "/usr/lib/python2.6/site-packages/ipapython/kernel_keyring.py", line 45, in get_real_key > (stdout, stderr, rc) = run(['keyctl', 'search', KEYRING, KEYTYPE, key], raiseonerr=False) > File "/usr/lib/python2.6/site-packages/ipapython/ipautil.py", line 295, in run > close_fds=True, env=env, cwd=cwd) > File "/usr/lib64/python2.6/subprocess.py", line 639, in __init__ > errread, errwrite) > File "/usr/lib64/python2.6/subprocess.py", line 1220, in _execute_child > raise child_exception > OSError: [Errno 2] No such file or directory > ======= > > Is that normal? No, absolutely not. I will let people knowledgeable about kernel keyrings to chime in. > Do i need to add entries to the hosts file on every client? Could you try this? 0) Restore your original /etc/hosts file (i.e. delete the line for IPA servers). 1) Run command "tcpdump -s 65535 -w /tmp/some_writeable_file -i any" on the client. 2) Run ipa-client-install 3) Stop tcpdump and send us the /tmp/some_writeable_file file. You can do it privately (for example to me or mkosek). The network capture will not contain any password but it will reveal domain names and IP addresses. Your problem is most probably related to name resolution but I can't see where the problem is from your description, I hope that the network trace will reveal it. Note: If you have some local caching DNS resolver *on the client* (unbound, BIND etc.), please flush it's caches before you start. Petr^2 Spacek > ________________________________________ > From: Martin Kosek [mkosek at redhat.com] > Sent: Friday, November 29, 2013 8:49 PM > To: Les Stott; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] gssapi sasl error - only picking up short hostname when running ipa-client-install (and failing) > > On 11/29/2013 09:16 AM, Les Stott wrote: >> Hi, >> >> Recently installed freeipa on two servers in multi-master mode. We want to have a central authentication system for many hosts. Environment is RHEL 6.4 for servers, RHEL 6.1 for the first client host, standard rpm packages used - ipa-server-3.0.0-26.el6_4.4.x86_64 and ipa-client-3.0.0-37.el6.x86_64. >> >> I am now trying to add the first linux host to freeipa via ipa-client-install. >> >> When I run ipa-client-install on a host in debug mode it fails with errors below (I have changed hostnames and ip's, freeipa-1.mydomain.com 192.168.1.22 and freeipa-2.mydomain.com 192.168.1.23, host client - host1 192.168.1.15) >> >> trying to retrieve CA cert via LDAP from ldap://freeipa-1.mydomain.com >> get_ca_cert_from_ldap() error: Local error SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Server ldap/freeipa-1 at MYDOMAIN.COM not found in Kerberos database) >> {'info': 'SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Server ldap/freeipa-1 at MYDOMAIN.COM not found in Kerberos database)', 'desc': 'Local error'} >> >> The Kerberos logs on the server (free-ipa-1) show >> Nov 29 01:46:14 freeipa-1.mydomain.com krb5kdc[1616](info): TGS_REQ (4 etypes {18 17 16 23}) 192.168.1.15: UNKNOWN_SERVER: authtime 0, admin@ MYDOMAIN.COM for HTTP/ freeipa-1 at MYDOMAIN.COM, Server not found in Kerberos database >> >> The logs indicate that the service name is being used with the short hostname (HTTP/ freeipa-1 at MYDOMAIN.COM). The FreeIPA server has records for HTTP/ freeipa-1.mydomain.com at MYDOMAIN.COM. I can see these in the web interface. I believe this is where it is stumbling. >> >> I've been banging my head against the wall on this one for a couple of days. Everything I've found says make sure you have working dns, make sure you can reverse lookup ip's, make sure hostnames are fqdn, make sure /etc/hosts on server has ip's for servers listed with fqdn first and shortname second. I've done all that. > > What about /etc/hosts on the clients? Do they also have FQDN first in case they > have server IP in there? From mkosek at redhat.com Fri Nov 29 13:30:29 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 29 Nov 2013 14:30:29 +0100 Subject: [Freeipa-users] gssapi sasl error - only picking up short hostname when running ipa-client-install (and failing) In-Reply-To: <4ED173A868981548967B4FCA2707222601E521@AACMBXP04.exchserver.com> References: <4ED173A868981548967B4FCA2707222601E1BD@AACMBXP04.exchserver.com>, <52986338.4000106@redhat.com> <4ED173A868981548967B4FCA2707222601E521@AACMBXP04.exchserver.com> Message-ID: <529896F5.2060601@redhat.com> On 11/29/2013 02:20 PM, Les Stott wrote: > Martin, > > there is no entries in /etc/hosts for the freeipa servers on the client. > the clients hosts own entry is there with fqdn first. > > Because you mentioned it, i added the hostname of both freeipa server to the hosts file on the client. It actually ran and setup the client. However it did get the following errors at the end after it did kerberos config.... I checked the spec file for RHEL-6.4 and this is a bug (already fixed in current upstream version). It does not include "keyutils" dependency. Thus, the dependency may be missing in some super minimal RHELs and cause this error. If you manuall install keyutils, this error should vanish. # yum install keyutils > > ======= > Configured /etc/krb5.conf for IPA realm MYDOMAIN.COM > Traceback (most recent call last): > File "/usr/sbin/ipa-client-install", line 2377, in > sys.exit(main()) > File "/usr/sbin/ipa-client-install", line 2363, in main > rval = install(options, env, fstore, statestore) > File "/usr/sbin/ipa-client-install", line 2135, in install > delete_persistent_client_session_data(host_principal) > File "/usr/lib/python2.6/site-packages/ipalib/rpc.py", line 124, in delete_persistent_client_session_data > kernel_keyring.del_key(keyname) > File "/usr/lib/python2.6/site-packages/ipapython/kernel_keyring.py", line 99, in del_key > real_key = get_real_key(key) > File "/usr/lib/python2.6/site-packages/ipapython/kernel_keyring.py", line 45, in get_real_key > (stdout, stderr, rc) = run(['keyctl', 'search', KEYRING, KEYTYPE, key], raiseonerr=False) > File "/usr/lib/python2.6/site-packages/ipapython/ipautil.py", line 295, in run > close_fds=True, env=env, cwd=cwd) > File "/usr/lib64/python2.6/subprocess.py", line 639, in __init__ > errread, errwrite) > File "/usr/lib64/python2.6/subprocess.py", line 1220, in _execute_child > raise child_exception > OSError: [Errno 2] No such file or directory > ======= > > Is that normal? No. > > Do i need to add entries to the hosts file on every client? By all means no, you should not need to do that if your DNS is sane and working. But if the addition to /etc/hosts helped, there must be something wrong with the DNS. Maybe there are wrong DNS PTR records cached? Do you have nscd daemon running? Are you 100% sure that the software on the client machine resolves the FQDN of the server when doing a reverse search? $ host $IPA_SERVER_IP HTH, Martin From abokovoy at redhat.com Fri Nov 29 13:32:09 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 29 Nov 2013 15:32:09 +0200 Subject: [Freeipa-users] gssapi sasl error - only picking up short hostname when running ipa-client-install (and failing) In-Reply-To: <4ED173A868981548967B4FCA2707222601E1BD@AACMBXP04.exchserver.com> References: <4ED173A868981548967B4FCA2707222601E1BD@AACMBXP04.exchserver.com> Message-ID: <20131129133209.GW21264@redhat.com> On Fri, 29 Nov 2013, Les Stott wrote: >Hi, > >Recently installed freeipa on two servers in multi-master mode. We want to have a central authentication system for many hosts. Environment is RHEL 6.4 for servers, RHEL 6.1 for the first client host, standard rpm packages used - ipa-server-3.0.0-26.el6_4.4.x86_64 and ipa-client-3.0.0-37.el6.x86_64. > >I am now trying to add the first linux host to freeipa via ipa-client-install. > >When I run ipa-client-install on a host in debug mode it fails with errors below (I have changed hostnames and ip's, freeipa-1.mydomain.com 192.168.1.22 and freeipa-2.mydomain.com 192.168.1.23, host client - host1 192.168.1.15) > >trying to retrieve CA cert via LDAP from ldap://freeipa-1.mydomain.com >get_ca_cert_from_ldap() error: Local error SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Server ldap/freeipa-1 at MYDOMAIN.COM not found in Kerberos database) >{'info': 'SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Server ldap/freeipa-1 at MYDOMAIN.COM not found in Kerberos database)', 'desc': 'Local error'} > >The Kerberos logs on the server (free-ipa-1) show >Nov 29 01:46:14 freeipa-1.mydomain.com krb5kdc[1616](info): TGS_REQ (4 etypes {18 17 16 23}) 192.168.1.15: UNKNOWN_SERVER: authtime 0, admin@ MYDOMAIN.COM for HTTP/ freeipa-1 at MYDOMAIN.COM, Server not found in Kerberos database > >The logs indicate that the service name is being used with the short hostname (HTTP/ freeipa-1 at MYDOMAIN.COM). The FreeIPA server has records for HTTP/ freeipa-1.mydomain.com at MYDOMAIN.COM. I can see these in the web interface. I believe this is where it is stumbling. > >I've been banging my head against the wall on this one for a couple of days. Everything I've found says make sure you have working dns, make sure you can reverse lookup ip's, make sure hostnames are fqdn, make sure /etc/hosts on server has ip's for servers listed with fqdn first and shortname second. I've done all that. > >I am using external dns (not integrated with freeipa), and have populated all records required as per sample config files provided during install. My time servers are other servers too, but that shouldn't matter, everything is in sync. > >; for Kerberos Auto Discovery >; ldap servers >_ldap._tcp IN SRV 0 100 389 freeipa-1.mydomain.com. >_ldap._tcp IN SRV 0 100 389 freeipa-2.mydomain.com. > >;kerberos realm >_kerberos IN TXT MYDOMAIN.COM > >; kerberos servers >_kerberos._tcp IN SRV 0 100 88 freeipa-1.mydomain.com. >_kerberos._tcp IN SRV 0 100 88 freeipa-2.mydomain.com. >_kerberos._udp IN SRV 0 100 88 freeipa-1.mydomain.com. >_kerberos._ucp IN SRV 0 100 88 freeipa-2.mydomain.com. >_kerberos-master._tcp IN SRV 0 100 88 freeipa-1.mydomain.com. >_kerberos-master._tcp IN SRV 0 100 88 freeipa-2.mydomain.com. >_kerberos-master._udp IN SRV 0 100 88 freeipa-1.mydomain.com. >_kerberos-master._udp IN SRV 0 100 88 freeipa-2.mydomain.com. >_kpasswd._tcp IN SRV 0 100 464 freeipa-1.mydomain.com. >_kpasswd._tcp IN SRV 0 100 464 freeipa-2.mydomain.com. >_kpasswd._udp IN SRV 0 100 464 freeipa-1.mydomain.com. >_kpasswd._udp IN SRV 0 100 464 freeipa-2.mydomain.com. > >;ntp server >_ntp._udp IN SRV 0 100 123 ntp1.mydomain.com. >_ntp._udp IN SRV 0 100 123 ntp2.mydomain.com. > >Reverse dns entries are also available and both freeipa servers and the host I am trying to configure ipa-client on can do lookups and receive fqdn's. They can all do reverse lookups that resolve correctly. > >I have read that when using SASL/GSSAPI (Kerberos) authentication, its possible that the service provider sets the principal name (SPN) to "ldap/servername" in the TGS_REQ based on a dns query of the PTR record. I do have PTR's configured, and they have FQDN's. Is it true that this happens with GSSAPI? If so how can I get around that? > >Reverse Zone File for 192.168.1 >22 PTR freeipa-1.mydomain.com. >23 PTR freeipa-2.mydomain.com. > >Nslookup results for each IP: >22.1.168.192.in-addr.arpa name = freeipa-1.mydomain.com. >23.1.168.192.in-addr.arpa name = freeipa-2.mydomain.com. > >I can authenticate using kinit before running the script and it still doesn't work. > >The short version of running the install shows: >Discovery was successful! >Hostname: host1.mydomain.com >Realm: MYDOMAIN.COM >DNS Domain: mydomain.com >IPA Server: freeipa-1.mydomain.com >BaseDN: dc=mydomain,dc=com > >It authenticates correctly with the admin user for enrolling the host, but joining the realm fails. > >I've tried everything I can think of. Can you show your resolv.conf? Can it be that it actually misses domain mydomain.com stanza? -- / Alexander Bokovoy From jhrozek at redhat.com Fri Nov 29 13:48:29 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 29 Nov 2013 14:48:29 +0100 Subject: [Freeipa-users] local root can su to any IPA user In-Reply-To: <20131129131101.GV21264@redhat.com> References: <20131129131101.GV21264@redhat.com> Message-ID: <20131129134829.GA4430@hendrix.redhat.com> On Fri, Nov 29, 2013 at 03:11:01PM +0200, Alexander Bokovoy wrote: > On Fri, 29 Nov 2013, Fred van Zwieten wrote: > >Hi, > > > >When being root on an ipa-client, I can su to any IPA user. This is > >somewhat unexptected behaviour in comparison to Windows. If I am local > >administrator in a windows AD member server, I cannot become a domain user. > >I need to be domain administrator for that. > > > >Is it possible to have this "feature" disabled somehow? > root user on Linux systems by default has CAP_SETUID capability which > allows to change process uid to a different user. If the capability is > there, the only way to reduce transition from a specific user to another > one is by confining it via appropriate security module, for example, > through properly defined SELinux policy that prevents a root to > transition to the context of an IPA user. Someone needs to write this > policy and deploy at IPA clients first. I think Fred is actually referring to the pam_rootok.so module that always returns PAM_SUCCESS if the caller has UID 0. Fred, if you comment out the line with "pam_rootok.so" in the file /etc/pam.d/su can you still log in as any user from root? From fvzwieten at vxcompany.com Fri Nov 29 14:08:44 2013 From: fvzwieten at vxcompany.com (Fred van Zwieten) Date: Fri, 29 Nov 2013 15:08:44 +0100 Subject: [Freeipa-users] local root can su to any IPA user In-Reply-To: <20131129134829.GA4430@hendrix.redhat.com> References: <20131129131101.GV21264@redhat.com> <20131129134829.GA4430@hendrix.redhat.com> Message-ID: Jakub, Yes, I could do this. But then the local root account cannot su to local users (without password). But that is actually a normal use-case. I just think local root should not be allowed to transition to a domain user, by default. Fred On Fri, Nov 29, 2013 at 2:48 PM, Jakub Hrozek wrote: > On Fri, Nov 29, 2013 at 03:11:01PM +0200, Alexander Bokovoy wrote: > > On Fri, 29 Nov 2013, Fred van Zwieten wrote: > > >Hi, > > > > > >When being root on an ipa-client, I can su to any IPA user. This is > > >somewhat unexptected behaviour in comparison to Windows. If I am local > > >administrator in a windows AD member server, I cannot become a domain > user. > > >I need to be domain administrator for that. > > > > > >Is it possible to have this "feature" disabled somehow? > > root user on Linux systems by default has CAP_SETUID capability which > > allows to change process uid to a different user. If the capability is > > there, the only way to reduce transition from a specific user to another > > one is by confining it via appropriate security module, for example, > > through properly defined SELinux policy that prevents a root to > > transition to the context of an IPA user. Someone needs to write this > > policy and deploy at IPA clients first. > > I think Fred is actually referring to the pam_rootok.so module that > always returns PAM_SUCCESS if the caller has UID 0. > > Fred, if you comment out the line with "pam_rootok.so" in the file > /etc/pam.d/su can you still log in as any user from root? > > _______________________________________________ > 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 jhrozek at redhat.com Fri Nov 29 14:17:11 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 29 Nov 2013 15:17:11 +0100 Subject: [Freeipa-users] local root can su to any IPA user In-Reply-To: References: <20131129131101.GV21264@redhat.com> <20131129134829.GA4430@hendrix.redhat.com> Message-ID: <20131129141711.GE4430@hendrix.redhat.com> On Fri, Nov 29, 2013 at 03:08:44PM +0100, Fred van Zwieten wrote: > Jakub, > > Yes, I could do this. But then the local root account cannot su to local > users (without password). But that is actually a normal use-case. I just > think local root should not be allowed to transition to a domain user, by > default. > > Fred Ah, in that case I'm not sure if there's an easy solution, at least I don't know any off hand. I think Alexander is right that SELinux would be a good choice. From mkosek at redhat.com Fri Nov 29 14:41:16 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 29 Nov 2013 15:41:16 +0100 Subject: [Freeipa-users] local root can su to any IPA user In-Reply-To: <20131129141711.GE4430@hendrix.redhat.com> References: <20131129131101.GV21264@redhat.com> <20131129134829.GA4430@hendrix.redhat.com> <20131129141711.GE4430@hendrix.redhat.com> Message-ID: <5298A78C.1090400@redhat.com> On 11/29/2013 03:17 PM, Jakub Hrozek wrote: > On Fri, Nov 29, 2013 at 03:08:44PM +0100, Fred van Zwieten wrote: >> Jakub, >> >> Yes, I could do this. But then the local root account cannot su to local >> users (without password). But that is actually a normal use-case. I just >> think local root should not be allowed to transition to a domain user, by >> default. >> >> Fred > > Ah, in that case I'm not sure if there's an easy solution, at least I > don't know any off hand. I think Alexander is right that SELinux would > be a good choice. Right. Root could uncomment the pam_rootok.so line anyway if he wanted to access other user's account again. Martin From erinn.looneytriggs at gmail.com Fri Nov 29 20:35:46 2013 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Fri, 29 Nov 2013 13:35:46 -0700 Subject: [Freeipa-users] Dogtag not working? In-Reply-To: <5297C8D2.4080407@gmail.com> References: <5297C8D2.4080407@gmail.com> Message-ID: <5298FAA2.8060000@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/28/2013 03:50 PM, Erinn Looney-Triggs wrote: > In the process of prepping a replication host for changing over the > CA I had to use certmonger to generate another certificate on my > secondary IPA server. Unfortunately it seems to fail every single > time. Here is what I am running and here is what I am getting: > > ipa-getcert request -k private/ipa2.abaqis.com.key -f > certs/ipa2.abaqis.com.crt -g 2048 > > The request appears to work, however when checking the list I > receive the following: > > ipa-getcert list -r Number of certificates and requests being > tracked: 9. Request ID '20131128202128': status: CA_UNREACHABLE > ca-error: Server failed request, will retry: 4301 (RPC failed at > server. Certificate operation cannot be completed: FAILURE > (Authentication Error)). stuck: yes key pair storage: > type=FILE,location='/etc/pki/tls/private/ipa2.abaqis.com.key' > certificate: > type=FILE,location='/etc/pki/tls/certs/ipa2.abaqis.com.crt' CA: > IPA issuer: subject: expires: unknown pre-save command: post-save > command: track: yes auto-renew: yes > > Fine, I check the http logs and get about the same: [Thu Nov 28 > 22:03:06 2013] [error] ipa: ERROR: > ipaserver.plugins.dogtag.ra.request_certificate(): FAILURE > (Authentication Error) > > Now as I understand it ipa-getcert is going to theserver listed in > /etc/ipa/default.conf, which in this case is ipa2.abaqis.com (the > request is coming from the same host). The host principle in > /etc/krb5.keytab is used for authentication. > > I have tested against the primary ipa server and everything works > as it should. However, any requests going against ipa2 for > certificates are failing. > > At this point I am stuck, so any suggestions are welcome. > > -Erinn > > Replying to myself here, and narrowing this down a bit further this seems to be a straight auth problem against my secondary ipa server. All command work against the primary, all certificate commands against the secondary fail. It appears to be confined to dogtag (other commands like ipa user-show work), but how exactly dogtag handles auth I am not clear on. It appears as though mod_auth_kerb handles most things and that is definitely working. However any access against dogtag components is failing, so dogtag must/should/may be handling auth internally in a way that is failing. Anyway, suggestions are still welcome, - -Erinn -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) iQEcBAEBAgAGBQJSmPqdAAoJENetaK3v/E7PxzkIAIJ6PbRoyZZBz1JBLP/iD20v L/Knolw1w9ZVUXlqFjsw8ZmSXZ15d6aSB5FBBM3mFeYK4XH/e3PEKAw3H51uxw/p 3WNQ8UmFH9/RowMwkK91DTMvim6KC7rAReQVJQ9PbMb/6Koyqceaiklf+RauTW79 t0Ls8l+ywk+oF/IeAQqk5ZkCS4gLRLJ8UgO/XkoG9vI755TAO9GGii52MDRmnShI mB+ojJZaKIKkD3Xe37VmiIw51+XeD98Tkzg9Ytommw7LDoYk4QCeaxa8+0jx2i3/ rlFMUtGW3E9gwLbjTGH6xX62lwqWCvjk6lnCl0oSdH/hmEQX78Sfno3XDltTjXs= =NEc+ -----END PGP SIGNATURE----- From andrewprecht06 at gmail.com Wed Nov 27 17:43:12 2013 From: andrewprecht06 at gmail.com (Andrew Precht) Date: Wed, 27 Nov 2013 09:43:12 -0800 Subject: [Freeipa-users] Ubuntu 12.04 and FreeIPA Message-ID: Hi users, I'm trying to get Ubuntu 12.04 to use FreeIPA as its directory service. I'm getting this error: host_mod: 2.58 client incompatible with 2.46 server at u' https://ipa1.example.com/ipa/xml' Failed to upload host SSH public keys. This seems to be the same as: https://fedorahosted.org/freeipa/ticket/3931 which is marked as: (closed defect: fixed) Is there a work around? Thanks, Andrew -------------- next part -------------- An HTML attachment was scrubbed... URL: