[Freeipa-users] Migration Webpage doesnt work
Hi, i migrated user data with the ipa migrate-ds script without problems. The users in the old OpenLDAP doesnt have a userPasswort and only the kerberos principal from local KRB DB was used for authentification. After migration FreeIPA doesnt have a userPassword and there is no Kerberos hash. Know i tried out the /ipa/migration webpage and want to set a userPassword/Kerberos hash for a user in FreeIPA. The result was the error message i entered the wrong password or/and username. Now my question is what is the requirement for the migration webpage to work ? The documentation says that migration webpage takes a cleartext password and generates the kerberos hash. Does the migration page need a userPassword entry ? I tried out to reset the pssword of a user in the WebUI and the migration webpage works with this password from the manual passwort reset ?! cheers, Andreas smime.p7s Description: S/MIME Cryptographic Signature -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Migration Webpage doesnt work
On Thu, 06 Nov 2014, Andreas Ladanyi wrote: Hi, i migrated user data with the ipa migrate-ds script without problems. The users in the old OpenLDAP doesnt have a userPasswort and only the kerberos principal from local KRB DB was used for authentification. After migration FreeIPA doesnt have a userPassword and there is no Kerberos hash. Know i tried out the /ipa/migration webpage and want to set a userPassword/Kerberos hash for a user in FreeIPA. The result was the error message i entered the wrong password or/and username. Now my question is what is the requirement for the migration webpage to work ? The documentation says that migration webpage takes a cleartext password and generates the kerberos hash. Does the migration page need a userPassword entry ? /ipa/migration page expects that you have a password hash in userPassword attribute set but no Kerberos hashes. It binds to LDAP server using the password user entered on the page and then IPA's plugin performs generation of Kerberos hashes as part of LDAP BIND operation. I tried out to reset the pssword of a user in the WebUI and the migration webpage works with this password from the manual passwort reset ?! When you reset the password, all hashes (including Kerberos ones) are generated and then user can change the password either through main login page or the migration page. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] dns stops working after upgrade
On 11/05/2014 05:22 PM, Rob Verduijn wrote: I saw in the upstream foreman-prepare-realm script that the new permission names should include a prefix System: That Prefix is not there, what did change was that some permissions where no longer lower case only. ie in 3.3.5 the permission is 'write dns configuration' and in 4.1 it becomes 'Write DNS Configuration' Rob Right. There were some changes to IPA's default policy too, but I don't think it should affect the Foreman proxy very much. For example there are now permissions for reading data, but most are granted to all authenticated users by default. I've left some comments in the pull request. 2014-11-05 16:25 GMT+01:00 Petr Spacek pspa...@redhat.com mailto:pspa...@redhat.com: On 5.11.2014 16:20, Rob Verduijn wrote: Hello, Yes I noticed the name change it took me a while to realise it was a known ruby bug in katello that caused the real problem. I also checked after I updated the 'katello integrated' update from 3.3.5 to 4.1 and the permissions were neatly renamed to their new counterparts. However the internal dns no longer worked :( So the permissions broke after upgrade to 4.1, right? pviktori, can you give us some advice? Thanks! Petr^2 Spacek Rob 2014-11-05 16:17 GMT+01:00 Stephen Benjamin step...@redhat.com mailto:step...@redhat.com: On Wed, Nov 05, 2014 at 09:41:59AM -0500, Rob Crittenden wrote: Also when I look at the permissions in ipa there are no longer any permissions that have the 'System: ' prefix. AFAIK the foreman proxy is not necessary (and not supported) with IPA 4.x because it was obsoleted by 'native' proxy delivered by Foreman upstream. Am I right, Rob (Crittenden)? :-) I believe he's referring to the native smart proxy here. It includes a script to setup permissions. I guess it hasn't been tested against a 4.x IPA master. The permissions have changed names in FreeIPA 4.0, which means the script won't work. I've tested this one against 4.1 on F21 and it works: https://raw.githubusercontent.__com/stbenjam/smart-proxy/8278/__sbin/foreman-prepare-realm https://raw.githubusercontent.com/stbenjam/smart-proxy/8278/sbin/foreman-prepare-realm There's an open pull request against foreman's Smart Proxy to include that in the next release: https://github.com/theforeman/__smart-proxy/pull/231-- https://github.com/theforeman/smart-proxy/pull/231-- -- Petr³ -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
[Freeipa-users] FreeIPA unresponsive - Causes DOS situations
Hi, I need some assistance please. I've taken over an IPA server to manage a few months ago, and it was working fine until recently when it started acting up seemingly off its own accord. When I do an ipactl status it basically gives an output as shown below: *Directory Service: RUNNING* *Loong pause... (To the tune of 7 minutes sometimes)* *KDC Service: RUNNING* *KPASSWD Service: RUNNING* *DNS Service: RUNNING* *MEMCACHE Service: RUNNING* *HTTP Service: RUNNING* *CA Service: RUNNING* *ADTRUST Service: RUNNING* *EXTID Service: RUNNING* Running top showed that ns-slapd was munching almost all my resources, but I got that fixed by upping the cache. Unfortunately this did not correct the issue and it still reacts in the same fashion, although the resources have been freed up now. I've noticed that when I run dig on either the local server or a remote machine that the query basically just times out as shown here: *dig freeipa.myexample.sample* *; DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 freeipa.myexample.sample* *;; global options: +cmd* *;; connection timed out; no servers could be reached* When the KDC service fails to start, then name lookups seem OK, but authentication fails. otherwise it's dead in the water. This also happens: *sudo ipactl status* *Directory Service: RUNNING* *Unknown error when retrieving list of services from LDAP:* My software setup is as follows: *CentOS release 6.5 (Final)* *389-ds-base.x86_64 1.2.11.15-34.el6_5* *bind.x86_64 32:9.8.2-0.23.rc1.el6_5.1* *bind-dyndb-ldap.x86_64* *bind-libs.x86_64 32:9.8.2-0.23.rc1.el6_5.1* *bind-utils.x86_6432:9.8.2-0.23.rc1.el6_5.1* *rpcbind.x86_64 0.2.0-11.el6 @anaconda-CentOS-201311291202.x86_64/6.5* *samba4-winbind.x86_64* *krb5-server.x86_64 1.10.3-15.el6_5.1* *Linux 2.6.32-431.29.2.el6.x86_64 #1 SMP Tue Sep 9 21:36:05 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux* It's not a permanent situation as it sometimes runs 100% for a while, but 80% of the time it is unusable. If anybody can assist me, please be so kind. Regards, Walter -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] FreeIPA unresponsive - Causes DOS situations
On 06/11/14 14:58, Walter van Lille wrote: Hi, I need some assistance please. I've taken over an IPA server to manage a few months ago, and it was working fine until recently when it started acting up seemingly off its own accord. When I do an ipactl status it basically gives an output as shown below: *Directory Service: RUNNING * * * *Loong pause... (To the tune of 7 minutes sometimes)* * * *KDC Service: RUNNING* *KPASSWD Service: RUNNING* *DNS Service: RUNNING* *MEMCACHE Service: RUNNING* *HTTP Service: RUNNING* *CA Service: RUNNING* *ADTRUST Service: RUNNING* *EXTID Service: RUNNING* Running top showed that ns-slapd was munching almost all my resources, but I got that fixed by upping the cache. Unfortunately this did not correct the issue and it still reacts in the same fashion, although the resources have been freed up now. I've noticed that when I run dig on either the local server or a remote machine that the query basically just times out as shown here: *dig freeipa.myexample.sample* * * *; DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 freeipa.myexample.sample* *;; global options: +cmd* *;; connection timed out; no servers could be reached* When the KDC service fails to start, then name lookups seem OK, but authentication fails. otherwise it's dead in the water. This also happens: *sudo ipactl status* *Directory Service: RUNNING* *Unknown error when retrieving list of services from LDAP:* * * My software setup is as follows: *CentOS release 6.5 (Final) * *389-ds-base.x86_64 1.2.11.15-34.el6_5 * *bind.x86_64 32:9.8.2-0.23.rc1.el6_5.1 * *bind-dyndb-ldap.x86_64* *bind-libs.x86_64 32:9.8.2-0.23.rc1.el6_5.1* *bind-utils.x86_6432:9.8.2-0.23.rc1.el6_5.1* *rpcbind.x86_64 0.2.0-11.el6 @anaconda-CentOS-201311291202.x86_64/6.5* *samba4-winbind.x86_64* *krb5-server.x86_64 1.10.3-15.el6_5.1 * * * *Linux 2.6.32-431.29.2.el6.x86_64 #1 SMP Tue Sep 9 21:36:05 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux * It's not a permanent situation as it sometimes runs 100% for a while, but 80% of the time it is unusable. If anybody can assist me, please be so kind. Regards, Walter Hello please which version of bind-dyndb-ldap do you use? I had similar issue with bind-dyndb-ldap, but it was development version, I'm not sure if this is your case. When named was failing, dirserv was really slow. Can you send journalctl -b -u named log when dig doesn't work?? -- Martin Basti -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] FreeIPA unresponsive - Causes DOS situations
On 11/06/2014 10:00 AM, Martin Basti wrote: On 06/11/14 14:58, Walter van Lille wrote: Hi, I need some assistance please. I've taken over an IPA server to manage a few months ago, and it was working fine until recently when it started acting up seemingly off its own accord. When I do an ipactl status it basically gives an output as shown below: *Directory Service: RUNNING * * * *Loong pause... (To the tune of 7 minutes sometimes)* * * *KDC Service: RUNNING* *KPASSWD Service: RUNNING* *DNS Service: RUNNING* *MEMCACHE Service: RUNNING* *HTTP Service: RUNNING* *CA Service: RUNNING* *ADTRUST Service: RUNNING* *EXTID Service: RUNNING* Running top showed that ns-slapd was munching almost all my resources, but I got that fixed by upping the cache. Unfortunately this did not correct the issue and it still reacts in the same fashion, although the resources have been freed up now. I've noticed that when I run dig on either the local server or a remote machine that the query basically just times out as shown here: *dig freeipa.myexample.sample* * * *; DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 freeipa.myexample.sample* *;; global options: +cmd* *;; connection timed out; no servers could be reached* When the KDC service fails to start, then name lookups seem OK, but authentication fails. otherwise it's dead in the water. This also happens: *sudo ipactl status* *Directory Service: RUNNING* *Unknown error when retrieving list of services from LDAP:* * * My software setup is as follows: *CentOS release 6.5 (Final) * *389-ds-base.x86_64 1.2.11.15-34.el6_5 * *bind.x86_64 32:9.8.2-0.23.rc1.el6_5.1 * *bind-dyndb-ldap.x86_64* *bind-libs.x86_64 32:9.8.2-0.23.rc1.el6_5.1* *bind-utils.x86_6432:9.8.2-0.23.rc1.el6_5.1* *rpcbind.x86_64 0.2.0-11.el6 @anaconda-CentOS-201311291202.x86_64/6.5* *samba4-winbind.x86_64* *krb5-server.x86_64 1.10.3-15.el6_5.1 * * * *Linux 2.6.32-431.29.2.el6.x86_64 #1 SMP Tue Sep 9 21:36:05 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux * It's not a permanent situation as it sometimes runs 100% for a while, but 80% of the time it is unusable. If anybody can assist me, please be so kind. Regards, Walter Hello please which version of bind-dyndb-ldap do you use? I had similar issue with bind-dyndb-ldap, but it was development version, I'm not sure if this is your case. When named was failing, dirserv was really slow. Can you send journalctl -b -u named log when dig doesn't work?? -- Martin Basti You also want to look at the directory server logs especially at startup and see what is it doing. Also check the diskspace. May be you do not have much room on the volume and it might cause DS to slow down. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] unable to sudo
As Bob pointed out in a direct e-mail to me, there was the detail of adding sudo and sss to /etc/nsswitch.conf but – once I did so, it pointed out that the Rackspace RHEL packaging that doesn’t provide what I need – possibly need from epel. # yum search /usr/lib64/libsss_sudo.so Loaded plugins: rhnplugin, security This system is receiving updates from RHN Classic or RHN Satellite. rackspace| 1.3 kB 00:00 rackspace-rhel-x86_64-server-6.5.z-common| 871 B 00:00 rackspace-rhel-x86_64-server-6.5.z-ius | 871 B 00:00 rhel-x86_64-server-6.5.z | 1.5 kB 00:00 rhel-x86_64-server-optional-6.5.z| 1.5 kB 00:00 rhn-tools-rhel-x86_64-server-6.5.z | 1.3 kB 00:00 vmware-tools | 951 B 00:00 Warning: No matches found for: /usr/lib64/libsss_sudo.so No Matches found Blockage identified, solution being searched Craig White System Administrator O 623-201-8179 M 602-377-9752 [cid:image001.png@01CF86FE.42D51630] SkyTouch Technology 4225 E. Windrose Dr. Phoenix, AZ 85032 From: t...@tetrioncapital.com [mailto:t...@tetrioncapital.com] Sent: Wednesday, November 05, 2014 6:11 PM To: Craig White; freeipa-users@redhat.com Subject: Re: [Freeipa-users] unable to sudo Hi, Did you config HBAC to allow sudo, then in sudo rules, allow your sudo command, next would be adding HBAC rules to user group? Sent from my BlackBerry 10 smartphone. From: Craig White Sent: Thursday, 6 November, 2014 6:11 AM To: freeipa-users@redhat.commailto:freeipa-users@redhat.com Subject: [Freeipa-users] unable to sudo First 10 ipa clients I set up – no problem. Set up 2 more, perhaps this is a problem with the fact that these 2 hosts were on a totally new VLAN and the firewall rules weren’t correct when I set them up. Been through the part on sudo here… http://www.freeipa.org/page/Troubleshooting nisdomainname is correct on the machines and also in /etc/sysconfig/network had to add ‘sudo’ to [sssd] services = nss, sudo, pam, ssh and restarted sssd though I don’t know why it wasn’t added automatically checked nsswitch.conf and netgroup is set to ‘files sss’ getent netgroup hgroup1 returns nothing on machines where sudo works and doesn’t work – can’t tell the difference. Added ‘sudoers_debug 2’ to /etc/sudo_ldap.conf but don’t know where that logs And finally, on a machine where ipa users cannot sudo… # sudo -l Matching Defaults entries for root on this host: requiretty, !visiblepw, always_set_home, env_reset, env_keep=COLORS DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR LS_COLORS, env_keep+=MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE, env_keep+=LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES, env_keep+=LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE, env_keep+=LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY, secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin User root may run the following commands on this host: (ALL) ALL $ sudo -l [sudo] password for craig.white: Sorry, user craig.white may not run sudo on 599330-stash001. Craig White System Administrator O 623-201-8179 M 602-377-9752 [cid:image001.png@01CF86FE.42D51630] SkyTouch Technology 4225 E. Windrose Dr. Phoenix, AZ 85032 -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] unable to sudo
On (06/11/14 15:42), Craig White wrote: As Bob pointed out in a direct e-mail to me, there was the detail of adding sudo and sss to /etc/nsswitch.conf but – once I did so, it pointed out that the Rackspace RHEL packaging that doesn’t provide what I need – possibly need from epel. # yum search /usr/lib64/libsss_sudo.so This file was in separate package in sssd 1.9. The packaging was changed in sssd = 1.10 and it is installed by default (part of package sssd-common) and rhel/CentOS 6.6 contains sssd 1.11.6 Loaded plugins: rhnplugin, security This system is receiving updates from RHN Classic or RHN Satellite. rackspace| 1.3 kB 00:00 rackspace-rhel-x86_64-server-6.5.z-common| 871 B 00:00 rackspace-rhel-x86_64-server-6.5.z-ius | 871 B 00:00 rhel-x86_64-server-6.5.z | 1.5 kB 00:00 rhel-x86_64-server-optional-6.5.z| 1.5 kB 00:00 rhn-tools-rhel-x86_64-server-6.5.z | 1.3 kB 00:00 vmware-tools | 951 B 00:00 Warning: No matches found for: /usr/lib64/libsss_sudo.so No Matches found Blockage identified, solution being searched Craig White System Administrator O 623-201-8179 M 602-377-9752 LS -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
[Freeipa-users] Announcing FreeIPA 4.0.5
The FreeIPA team would like to announce FreeIPA v4.0.5 security release! It can be downloaded from http://www.freeipa.org/page/Downloads. Builds for Fedora 21 are available in the official [https://copr.fedoraproject.org/coprs/mkosek/freeipa-4.0/ COPR repository]. == Highlights in 4.0.5 == === Bug fixes === * CVE-2014-7828: ensure that a password is provided in 2 factor authentication [http://www.freeipa.org/page/CVE-2014-7828] * fixed upgrade issue from FreeIPA 3.3.5 [https://fedorahosted.org/freeipa/ticket/4670] [https://fedorahosted.org/freeipa/ticket/4635] * prevent possible deadlocks with schema compatibility plugin == Upgrading == An IPA server can be upgraded simply by installing updated rpms. The server does not need to be shut down in advance. Please note that 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-ldap-updater --upgrade # ipa-upgradeconfig 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 3.3.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 4.0.4 == === Martin Basti (1) === * Fix upgrade: do not use invalid ldap connection === Nathaniel McCallum (1) === * Ensure that a password exists after OTP validation === Petr Vobornik (1) === * Become IPA 4.0.5 === Thierry bordaz (tbordaz) (1) === * Deadlock in schema compat plugin (between automember_update_membership task and dse update) -- Petr Vobornik -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
[Freeipa-users] missing package in 4.1.1 repo
Hi, There is a dependency error in the updated repo. I did a yum clean all then a yum update. I got this error: Error: Package: freeipa-server-4.1.1-1.fc20.x86_64 (mkosek-freeipa) Requires: slapi-nis = 0.54.1-1 Removing: slapi-nis-0.52-1.fc20.x86_64 (@private.updates) slapi-nis = 0.52-1.fc20 Updated By: slapi-nis-0.54-1.fc20.x86_64 (mkosek-freeipa) slapi-nis = 0.54-1.fc20 Available: slapi-nis-0.50-1.fc20.x86_64 (fedora) slapi-nis = 0.50-1.fc20 yum list --show-duplicates slapi-nis Installed Packages slapi-nis.x86_64 0.54-1.fc20 @mkosek-freeipa Available Packages slapi-nis.x86_64 0.50-1.fc20 private.base slapi-nis.x86_64 0.52-1.fc20 private.updates slapi-nis.x86_64 0.54-1.fc20 mkosek-freeipa there is no 0.54.1-1.fc20 version of slapi-nis Rob -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
[Freeipa-users] Announcing FreeIPA 4.1.1
The FreeIPA team would like to announce FreeIPA v4.1.1 security release! It can be downloaded from http://www.freeipa.org/page/Downloads. The builds will be available for Fedora 21. Builds for Fedora 20 are available in the official COPR repository [https://copr.fedoraproject.org/coprs/mkosek/freeipa/]. == Highlights in 4.1.1 == === Bug fixes === * CVE-2014-7828: ensure that a password is provided in 2 factor authentication [http://www.freeipa.org/page/CVE-2014-7828] * fixed upgrade issue from FreeIPA 3.3.5 [https://fedorahosted.org/freeipa/ticket/4670] [https://fedorahosted.org/freeipa/ticket/4635] * various bug fixes in CA management tools and DNS sec * Allow reading SSH public keys overrides of users * Allow reading GID value override for users * prevent possible deadlocks with schema compatibility plugin == Known Issues == * On Fedora 21 beta, FreeIPA server installation fails with SELinux in enforcing mode. == Upgrading == An IPA server can be upgraded simply by installing updated rpms. The server does not need to be shut down in advance. Please note that 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-ldap-updater --upgrade # ipa-upgradeconfig 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 3.3.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 4.1.0 == === Alexander Bokovoy (1) === * Add ipaSshPubkey and gidNumber to the ACI to read ID user overrides === David Kupka (2) === * Respect UID and GID soft static allocation. * Stop dirsrv last in ipactl stop. === Jan Cholasta (10) === * Do not check if port 8443 is available in step 2 of external CA install * Handle profile changes in dogtag-ipa-ca-renew-agent * Do not wait for new CA certificate to appear in LDAP in ipa-certupdate * Fail if certmonger can't see new CA certificate in LDAP in ipa-cacert-manage * Fix possible NULL dereference in ipa-kdb * Fix memory leaks in ipa-extdom-extop * Fix various bugs in ipa-opt-counter and ipa-otp-lasttoken * Fix memory leak in ipa-pwd-extop * Fix memory leaks in ipa-join * Fix various bugs in ipap11helper === Martin Basti (4) === * Fix dns zonemgr validation regression * Add bind-dyndb-ldap working dir to IPA specfile * Fix CI tests: install_adtrust * Fix upgrade: do not use invalid ldap connection === Nathaniel McCallum (1) === * Ensure that a password exists after OTP validation === Petr Spacek (1) === * Fix zone name to directory name conversion in BINDMgr. === Petr Vobornik (2) === * build: increase java stack size for all arches * Become IPA 4.1.1 === Thierry bordaz (tbordaz) (1) === * Deadlock in schema compat plugin (between automember_update_membership task and dse update) -- Petr Vobornik -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] missing package in 4.1.1 repo
On Thu, 06 Nov 2014, Rob Verduijn wrote: Hi, There is a dependency error in the updated repo. I did a yum clean all then a yum update. I got this error: Error: Package: freeipa-server-4.1.1-1.fc20.x86_64 (mkosek-freeipa) Requires: slapi-nis = 0.54.1-1 Removing: slapi-nis-0.52-1.fc20.x86_64 (@private.updates) slapi-nis = 0.52-1.fc20 Updated By: slapi-nis-0.54-1.fc20.x86_64 (mkosek-freeipa) slapi-nis = 0.54-1.fc20 Available: slapi-nis-0.50-1.fc20.x86_64 (fedora) slapi-nis = 0.50-1.fc20 yum list --show-duplicates slapi-nis Installed Packages slapi-nis.x86_64 0.54-1.fc20 @mkosek-freeipa Available Packages slapi-nis.x86_64 0.50-1.fc20 private.base slapi-nis.x86_64 0.52-1.fc20 private.updates slapi-nis.x86_64 0.54-1.fc20 mkosek-freeipa there is no 0.54.1-1.fc20 version of slapi-nis It is being rebuilt as we speak. https://copr.fedoraproject.org/coprs/mkosek/freeipa/build/57344/ -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] missing package in 4.1.1 repo
On Thu, 06 Nov 2014, Alexander Bokovoy wrote: On Thu, 06 Nov 2014, Rob Verduijn wrote: Hi, There is a dependency error in the updated repo. I did a yum clean all then a yum update. I got this error: Error: Package: freeipa-server-4.1.1-1.fc20.x86_64 (mkosek-freeipa) Requires: slapi-nis = 0.54.1-1 Removing: slapi-nis-0.52-1.fc20.x86_64 (@private.updates) slapi-nis = 0.52-1.fc20 Updated By: slapi-nis-0.54-1.fc20.x86_64 (mkosek-freeipa) slapi-nis = 0.54-1.fc20 Available: slapi-nis-0.50-1.fc20.x86_64 (fedora) slapi-nis = 0.50-1.fc20 yum list --show-duplicates slapi-nis Installed Packages slapi-nis.x86_64 0.54-1.fc20 @mkosek-freeipa Available Packages slapi-nis.x86_64 0.50-1.fc20 private.base slapi-nis.x86_64 0.52-1.fc20 private.updates slapi-nis.x86_64 0.54-1.fc20 mkosek-freeipa there is no 0.54.1-1.fc20 version of slapi-nis It is being rebuilt as we speak. https://copr.fedoraproject.org/coprs/mkosek/freeipa/build/57344/ Done and should be available. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Question about oVirt
On Tue, 2014-11-04 at 15:16 -0500, Dmitri Pal wrote: On 11/04/2014 01:27 PM, Dmitri Pal wrote: Hello Jim, I am re-posting your question to the FreeIPA list as it belongs there. Here is the copy of the original question. Subject: [ovirt-users] templates and freeipa From: Jim Kinney jim.kin...@gmail.com Date: 10/31/2014 02:55 PM To: us...@ovirt.org us...@ovirt.org Ovirt 3.5 is running well for me and I have freeIPA controlling access to the user portal. I would like to provide templates of various linux setups that all have freeipa for user authentication in the VM for my developers to be able to create a new VM from and then log in using their freeIPA access and sudo control. I'm wanting to group developers by project and use freeIPA to set sudo commands as needed (group A get oracle, group B get postgresql, etc). Wanting to maximize developer ability while minimizing my clean up time :-) They will be able to delete VMs they create. It's possible to do a kickstart deploy with freeIPA registration but a template from that will be a problem as it will have the same keys for all VMs. Is there a post-creation scripting process I can attach to in ovirt or should I look at a default root user and script that personalizes the new VM? -- -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. Which provisioning technique you are using? Would something like what Adam describes here [1] or Foreman uses here [2] would be relevant? [1] http://adam.younglogic.com/2013/09/register-vm-freeipa/ [2] http://theforeman.org/manuals/1.5/index.html#4.3.11FreeIPARealm -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. I'm currently using a pre-built template that the devs have access to clone from. The scripted process from Adam Young is what I'm looking at now. I've not grokked enough of Foreman yet to begin a test implementation. It looks to be more capable (the remove DNS entry on delete is a key thing) and will likely be the direction I go. -- Jim Kinney Senior System Administrator Department of BioMedical Informatics Emory University jimkin...@emory.edu 404.712.0300 bmi.emory.edu -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] unable to sudo
-Original Message- From: Lukas Slebodnik [mailto:lsleb...@redhat.com] Sent: Thursday, November 06, 2014 9:34 AM To: Craig White Cc: t...@tetrioncapital.com; freeipa-users@redhat.com Subject: Re: [Freeipa-users] unable to sudo On (06/11/14 15:42), Craig White wrote: As Bob pointed out in a direct e-mail to me, there was the detail of adding sudo and sss to /etc/nsswitch.conf but – once I did so, it pointed out that the Rackspace RHEL packaging that doesn’t provide what I need – possibly need from epel. # yum search /usr/lib64/libsss_sudo.so This file was in separate package in sssd 1.9. The packaging was changed in sssd = 1.10 and it is installed by default (part of package sssd-common) and rhel/CentOS 6.6 contains sssd 1.11.6 Unfortunately for me, Rackspace still has these boxes on RHEL 6.5 # rpm -qa | grep sssd sssd-client-1.9.2-129.el6_5.4.x86_64 sssd-1.9.2-129.el6_5.4.x86_64 nowhere to go I think - thanks -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
[Freeipa-users] Kerberos for cronjoob
Hi, Is it possible to renew ticket once in a while for cronjob to run on certain users? How do you guys run cronjob on Kerberos user without getting ticket expire? Sent from my BlackBerry 10 smartphone. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Kerberos for cronjoob
On 11/06/2014 08:20 PM, Thomas Lau wrote: ?Hi, Is it possible to renew ticket once in a while for cronjob to run on certain users? How do you guys run cronjob on Kerberos user without getting ticket expire? Sent from my BlackBerry 10 smartphone. Here is an example: http://adam.younglogic.com/2013/05/kerberizing-postgresql-with-freeipa-for-keystone/ But starting kerberos 1.11 kerberos library should be able to automatically renew the ticket for service accounts http://k5wiki.kerberos.org/wiki/Projects/Keytab_initiation -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Centos IPA Client fails after upgrade to 6.6
I am seeing somewhat similar behavior once upgrading from sssd 1.9 to 1.11 (centos 6.5 to 6.6) I seem to be able to log in via ssh, but when I use http pam service, I get inconsistent behavior - seems like sometimes it works and others it errors out (success and failure can happen within a second) In the logs I see things like: [sssd[krb5_child[15410]]]: Internal credentials cache error and authentication failure; logname= uid=48 euid=48 tty= ruser= rhost= user=username received for user username: 4 (System error) Nothing in the audit.log that I can see I am guessing this is an sssd issue but I am hoping someone here knows how to deal with it. IN case it matters - here is the pam config: authrequired pam_env.so authsufficientpam_sss.so authrequired pam_deny.so account [default=bad success=ok user_unknown=ignore] pam_sss.so account required pam_permit.so passwordrequisite pam_cracklib.so try_first_pass retry=3 type= passwordsufficientpam_sss.so use_authtok passwordrequired pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so session optional pam_oddjob_mkhomedir.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session optional pam_sss.so -M On Wed, Nov 5, 2014 at 1:05 AM, Jakub Hrozek jhro...@redhat.com wrote: On Wed, Nov 05, 2014 at 02:30:55AM +, David Taylor wrote: Thanks for the reply. The PAM file is pretty stock for a centos build #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. authrequired pam_env.so authsufficientpam_unix.so nullok try_first_pass authrequisite pam_succeed_if.so uid = 500 quiet authsufficientpam_sss.so use_first_pass authrequired pam_deny.so account required pam_unix.so account sufficientpam_localuser.so account sufficientpam_succeed_if.so uid 500 quiet account [default=bad success=ok user_unknown=ignore] pam_sss.so account required pam_permit.so passwordrequisite pam_cracklib.so try_first_pass retry=3 type= passwordsufficientpam_unix.so sha512 shadow nullok try_first_pass use_authtok passwordsufficientpam_sss.so use_authtok passwordrequired pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_sss.so Best regards David Taylor OK, so pam_sss is there ... And yet you see no mention of pam_sss.so in /var/log/secure ? Is this the file that was included from the service-specific PAM configuration? -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
[Freeipa-users] 3.0.0-42 Replication issue after Centos6.5-6.6 upgrade
Hello all :) On the whole we are loving FreeIPA, Many thanks and much respect to all involved, we’ve had a great 12-18 months hassle free use out of it - it is a fantastically stable trouble free solution… however now we’ve run into a small issue we (as mere mortals) are finding it hard to resolve :-/ We upgraded our ipa servers (3.0.0-42) to Centos 6.6. everything seems to go well, but one server is behaving oddly. It’s likely not an IPA issue, it also reset it’s hostname somehow after the upgrade (it’s an image in an openstack environment) If anyone has any pointers as to how to debug I’d be hugely appreciative :) Two servers, server1.domain.com and server2.domain.com Server1 can’t push data to server2, there are updates and new records on server1 that do not exist on server2. from the logs on server1: [07/Nov/2014:01:33:42 +] NSMMReplicationPlugin - agmt=cn=meToserver2.domain.com (server2:389): Warning: unable to send endReplication extended operation (Can't contact LDAP server) [07/Nov/2014:01:33:47 +] NSMMReplicationPlugin - agmt=cn=meToserver2.domain.com (server2:389): Replication bind with GSSAPI auth resumed [07/Nov/2014:01:33:48 +] NSMMReplicationPlugin - agmt=cn=meToserver2.domain.com (server2:389): Warning: unable to replicate schema: rc=2 [07/Nov/2014:01:33:48 +] NSMMReplicationPlugin - agmt=cn=meToserver2.domain.com (server2:389): Consumer failed to replay change (uniqueid (null), CSN (null)): Can't contact LDAP server(-1). Will retry later. and the servers: [root@server1 ~]# ipa-replica-manage list -v `hostname` Directory Manager password: server2.domain.com: replica last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update started last update ended: 2014-11-07 01:35:58+00:00 [root@server1 ~]# [root@server2 ~]# ipa-replica-manage list -v `hostname` Directory Manager password: server1.domain.com: replica last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2014-11-07 01:35:43+00:00 [root@server2 ~]# Will Sheldon -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Centos IPA Client fails after upgrade to 6.6
As an add on, I’ve upgraded our Xen template to 6.6 and run up a new VM using that and it attaches to the IPA environment perfectly well, so I’m guessing it is an issue with the upgrade scripts. Best regards David Taylor From: Michael Lasevich [mailto:mlasev...@gmail.com] Sent: Friday, 7 November 2014 4:00 PM To: Jakub Hrozek Cc: David Taylor; freeipa-users@redhat.com Subject: Re: [Freeipa-users] Centos IPA Client fails after upgrade to 6.6 I am seeing somewhat similar behavior once upgrading from sssd 1.9 to 1.11 (centos 6.5 to 6.6) I seem to be able to log in via ssh, but when I use http pam service, I get inconsistent behavior - seems like sometimes it works and others it errors out (success and failure can happen within a second) In the logs I see things like: [sssd[krb5_child[15410]]]: Internal credentials cache error and authentication failure; logname= uid=48 euid=48 tty= ruser= rhost= user=username received for user username: 4 (System error) Nothing in the audit.log that I can see I am guessing this is an sssd issue but I am hoping someone here knows how to deal with it. IN case it matters - here is the pam config: authrequired pam_env.so authsufficientpam_sss.so authrequired pam_deny.so account [default=bad success=ok user_unknown=ignore] pam_sss.so account required pam_permit.so passwordrequisite pam_cracklib.so try_first_pass retry=3 type= passwordsufficientpam_sss.so use_authtok passwordrequired pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so session optional pam_oddjob_mkhomedir.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session optional pam_sss.so -M On Wed, Nov 5, 2014 at 1:05 AM, Jakub Hrozek jhro...@redhat.commailto:jhro...@redhat.com wrote: On Wed, Nov 05, 2014 at 02:30:55AM +, David Taylor wrote: Thanks for the reply. The PAM file is pretty stock for a centos build #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. authrequired pam_env.so authsufficientpam_unix.so nullok try_first_pass authrequisite pam_succeed_if.so uid = 500 quiet authsufficientpam_sss.so use_first_pass authrequired pam_deny.so account required pam_unix.so account sufficientpam_localuser.so account sufficientpam_succeed_if.so uid 500 quiet account [default=bad success=ok user_unknown=ignore] pam_sss.so account required pam_permit.so passwordrequisite pam_cracklib.so try_first_pass retry=3 type= passwordsufficientpam_unix.so sha512 shadow nullok try_first_pass use_authtok passwordsufficientpam_sss.so use_authtok passwordrequired pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_sss.so Best regards David Taylor OK, so pam_sss is there ... And yet you see no mention of pam_sss.so in /var/log/secure ? Is this the file that was included from the service-specific PAM configuration? -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Centos IPA Client fails after upgrade to 6.6
For what its worth, my issue was resolved when I rebooted the server. Restarting sssd and/or clearing it's cache did not do it, but a full reboot seems to have done it. Something much have been cached or some temp file I missed. Will need to look into it further as I have a number of servers yet to be upgraded and having to reboot linux servers to do an upgrade seem sacrilegious... -M On Thu, Nov 6, 2014 at 9:26 PM, David Taylor david.tay...@speedcast.com wrote: As an add on, I’ve upgraded our Xen template to 6.6 and run up a new VM using that and it attaches to the IPA environment perfectly well, so I’m guessing it is an issue with the upgrade scripts. Best regards *David Taylor* *From:* Michael Lasevich [mailto:mlasev...@gmail.com] *Sent:* Friday, 7 November 2014 4:00 PM *To:* Jakub Hrozek *Cc:* David Taylor; freeipa-users@redhat.com *Subject:* Re: [Freeipa-users] Centos IPA Client fails after upgrade to 6.6 I am seeing somewhat similar behavior once upgrading from sssd 1.9 to 1.11 (centos 6.5 to 6.6) I seem to be able to log in via ssh, but when I use http pam service, I get inconsistent behavior - seems like sometimes it works and others it errors out (success and failure can happen within a second) In the logs I see things like: [sssd[krb5_child[15410]]]: Internal credentials cache error and authentication failure; logname= uid=48 euid=48 tty= ruser= rhost= user=username received for user username: 4 (System error) Nothing in the audit.log that I can see I am guessing this is an sssd issue but I am hoping someone here knows how to deal with it. IN case it matters - here is the pam config: authrequired pam_env.so authsufficientpam_sss.so authrequired pam_deny.so account [default=bad success=ok user_unknown=ignore] pam_sss.so account required pam_permit.so passwordrequisite pam_cracklib.so try_first_pass retry=3 type= passwordsufficientpam_sss.so use_authtok passwordrequired pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so session optional pam_oddjob_mkhomedir.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session optional pam_sss.so -M On Wed, Nov 5, 2014 at 1:05 AM, Jakub Hrozek jhro...@redhat.com wrote: On Wed, Nov 05, 2014 at 02:30:55AM +, David Taylor wrote: Thanks for the reply. The PAM file is pretty stock for a centos build #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. authrequired pam_env.so authsufficientpam_unix.so nullok try_first_pass authrequisite pam_succeed_if.so uid = 500 quiet authsufficientpam_sss.so use_first_pass authrequired pam_deny.so account required pam_unix.so account sufficientpam_localuser.so account sufficientpam_succeed_if.so uid 500 quiet account [default=bad success=ok user_unknown=ignore] pam_sss.so account required pam_permit.so passwordrequisite pam_cracklib.so try_first_pass retry=3 type= passwordsufficientpam_unix.so sha512 shadow nullok try_first_pass use_authtok passwordsufficientpam_sss.so use_authtok passwordrequired pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_sss.so Best regards David Taylor OK, so pam_sss is there ... And yet you see no mention of pam_sss.so in /var/log/secure ? Is this the file that was included from the service-specific PAM configuration? -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] 3.0.0-42 Replication issue after Centos6.5-6.6 upgrade
On 11/07/2014 12:18 AM, Will Sheldon wrote: Hello all :) On the whole we are loving FreeIPA, Many thanks and much respect to all involved, we've had a great 12-18 months hassle free use out of it - it is a fantastically stable trouble free solution... however now we've run into a small issue we (as mere mortals) are finding it hard to resolve :-/ We upgraded our ipa servers (3.0.0-42) to Centos 6.6. everything seems to go well, but one server is behaving oddly. It's likely not an IPA issue, it also reset it's hostname somehow after the upgrade (it's an image in an openstack environment) If anyone has any pointers as to how to debug I'd be hugely appreciative :) Two servers, server1.domain.com and server2.domain.com Server1 can't push data to server2, there are updates and new records on server1 that do not exist on server2. from the logs on server1: [07/Nov/2014:01:33:42 +] NSMMReplicationPlugin - agmt=cn=meToserver2.domain.com (server2:389): Warning: unable to send endReplication extended operation (Can't contact LDAP server) [07/Nov/2014:01:33:47 +] NSMMReplicationPlugin - agmt=cn=meToserver2.domain.com (server2:389): Replication bind with GSSAPI auth resumed [07/Nov/2014:01:33:48 +] NSMMReplicationPlugin - agmt=cn=meToserver2.domain.com (server2:389): Warning: unable to replicate schema: rc=2 [07/Nov/2014:01:33:48 +] NSMMReplicationPlugin - agmt=cn=meToserver2.domain.com (server2:389): Consumer failed to replay change (uniqueid (null), CSN (null)): Can't contact LDAP server(-1). Will retry later. Try to see a) Server 1 properly resolves server 2 b) You can connect from server 1 to server 2 using ldapsearch c) your firewall has proper ports open d) dirserver on server 2 is actually running Check logs on server 2 to see whether it actually sees an attempt to connect, I suspect not, so it is most likely a DNS/FW issue or dir server is not running on 2. and the servers: [root@server1 ~]# ipa-replica-manage list -v `hostname` Directory Manager password: server2.domain.com: replica last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update started last update ended: 2014-11-07 01:35:58+00:00 [root@server1 ~]# [root@server2 ~]# ipa-replica-manage list -v `hostname` Directory Manager password: server1.domain.com: replica last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2014-11-07 01:35:43+00:00 [root@server2 ~]# Will Sheldon -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] 3.0.0-42 Replication issue after Centos6.5-6.6 upgrade
On November 6, 2014 at 10:07:54 PM, Dmitri Pal (d...@redhat.com) wrote: On 11/07/2014 12:18 AM, Will Sheldon wrote: Hello all :) On the whole we are loving FreeIPA, Many thanks and much respect to all involved, we’ve had a great 12-18 months hassle free use out of it - it is a fantastically stable trouble free solution… however now we’ve run into a small issue we (as mere mortals) are finding it hard to resolve :-/ We upgraded our ipa servers (3.0.0-42) to Centos 6.6. everything seems to go well, but one server is behaving oddly. It’s likely not an IPA issue, it also reset it’s hostname somehow after the upgrade (it’s an image in an openstack environment) If anyone has any pointers as to how to debug I’d be hugely appreciative :) Two servers, server1.domain.com and server2.domain.com Server1 can’t push data to server2, there are updates and new records on server1 that do not exist on server2. from the logs on server1: [07/Nov/2014:01:33:42 +] NSMMReplicationPlugin - agmt=cn=meToserver2.domain.com (server2:389): Warning: unable to send endReplication extended operation (Can't contact LDAP server) [07/Nov/2014:01:33:47 +] NSMMReplicationPlugin - agmt=cn=meToserver2.domain.com (server2:389): Replication bind with GSSAPI auth resumed [07/Nov/2014:01:33:48 +] NSMMReplicationPlugin - agmt=cn=meToserver2.domain.com (server2:389): Warning: unable to replicate schema: rc=2 [07/Nov/2014:01:33:48 +] NSMMReplicationPlugin - agmt=cn=meToserver2.domain.com (server2:389): Consumer failed to replay change (uniqueid (null), CSN (null)): Can't contact LDAP server(-1). Will retry later. Try to see a) Server 1 properly resolves server 2 b) You can connect from server 1 to server 2 using ldapsearch c) your firewall has proper ports open d) dirserver on server 2 is actually running All seems working: [root@server1 ~]# ldapsearch -x -H ldap://server2.domain.com -s base -b '' namingContexts # extended LDIF # # LDAPv3 # base with scope baseObject # filter: (objectclass=*) # requesting: namingContexts # # dn: namingContexts: dc=domain,dc=com # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 [root@server1 ~]# And: [root@server2 ~]# /etc/init.d/dirsrv status dirsrv DOMAIN-COM (pid 1009) is running... dirsrv PKI-IPA (pid 1083) is running... [root@server2 ~]# Check logs on server 2 to see whether it actually sees an attempt to connect, I suspect not, so it is most likely a DNS/FW issue or dir server is not running on 2. and the servers: [root@server1 ~]# ipa-replica-manage list -v `hostname` Directory Manager password: server2.domain.com: replica last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update started last update ended: 2014-11-07 01:35:58+00:00 [root@server1 ~]# [root@server2 ~]# ipa-replica-manage list -v `hostname` Directory Manager password: server1.domain.com: replica last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2014-11-07 01:35:43+00:00 [root@server2 ~]# Will Sheldon -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project-- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Centos IPA Client fails after upgrade to 6.6
On (06/11/14 21:00), Michael Lasevich wrote: I am seeing somewhat similar behavior once upgrading from sssd 1.9 to 1.11 (centos 6.5 to 6.6) I seem to be able to log in via ssh, but when I use http pam service, I get inconsistent behavior - seems like sometimes it works and others it errors out (success and failure can happen within a second) In the logs I see things like: [sssd[krb5_child[15410]]]: Internal credentials cache error and authentication failure; logname= uid=48 euid=48 tty= ruser= rhost= user=username received for user username: 4 (System error) When pam_sss returned System error it meand unextected situation in sssd. If you are able to reproduce problem on another machine (youhave alredy restarted this one) could you provide log files from sssd? put debug_level = 7 into doman section of /etc/sssd/sssd.conf and log files will be stored in directory /var/log/sssd/ LS -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
