Re: [Freeipa-users] vsftpd PAM setup problem
Thanks, all good now. On Fri, Oct 31, 2014 at 1:40 PM, Alexander Bokovoy aboko...@redhat.com wrote: On Fri, 31 Oct 2014, Thomas Lau wrote: Hi All, I am using vsftpd and auth against PAM (eventually to sss), but I can't login even using admin account, anyone could provide some hints on how to make it work? here is the detail log on sssd_us.domain.com.log: You need to fix permissions of /tmp: [krb5_auth_prepare_ccache_name] (0x4000): Recreating ccache file. [check_parent_stat] (0x0020): Private directory can only be created below a directory belonging to root or to [121843][121843]. [create_ccache_dir] (0x0080): check_parent_stat failed for directory [/tmp]. [krb5_auth_prepare_ccache_name] (0x0040): ccache creation failed. [ipa_auth_handler_done] (0x0040): krb5_auth_recv request failed. [be_pam_handler_callback] (0x0100): Backend returned: (0, 4, NULL) [Success] -- / Alexander Bokovoy -- Thomas Lau Director of Infrastructure Tetrion Capital Limited Mobile: +852-9323-9670 Address: 20/F, IFC 1, Central district, Hong Kong -- 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] Errors upgrading 4.0.1 to 4.1
On 10/30/2014 07:36 PM, Martin Basti wrote: On 30/10/14 19:18, Michael Lasevich wrote: Makes sense. What is the solution here? I have the latest 389-ds installed but still getting allowWeakCipher error - how to I get around that? -M Sorry I don't know, I CCied Ludwig, he is DS guru. I already asked to verify the schema files: can you check your schema files for the definition of the nsEncryptionConfig objectclass, it should be only in 01core389.ldif and contain allowWeakCipher, but it could have been added also to 99user.ldif during replication when schema changes have been consolidated and what is the latest ds version you are using: rpm -q 389-ds-base Martin^2 On 10/30/14, 11:12 AM, Martin Basti wrote: On 24/10/14 05:17, Michael Lasevich wrote: While upgrading from 4.0.1. to 4.1 on fedora 20 got following on one of the two boxes: Upgrade failed with attribute allowWeakCipher not allowed IPA upgrade failed. Unexpected error DuplicateEntry: This entry already exists Named errors are caused by cascade effect, if ldap schema and entry updates failed, there is misconfigured DS plugin which is responsible to keep DNSSEC keys DN unique, what causes duplication errors. DuplicateEntry exception is fatal, so dnskeysyncd installation will not continue, what causes there are not appropriate permissions for token database, and named-pkcs11 can't read tokens. It seems the ipa no longer starts up after this. The replica server seems to have had same error,but it runs just fine. From digging around, it appears that there are a number of GSS errors in dirsrv and bind fails with something like: named-pkcs11[2212]: ObjectStore.cpp(74): Failed to open token e919db16-6329-406c-6ae4-120ad68508c4 named-pkcs11[2212]: sha1.c:92: fatal error: named-pkcs11[2212]: RUNTIME_CHECK(pk11_get_session(ctx, OP_DIGEST, isc_boolean_true, isc_boolean_false, isc_boolean_false, ((void *)0), 0) == 0) failed Any help would be appreciated -M -- Martin Basti -- 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] Centos IPA Client fails after upgrade to 6.6
On 31 Oct 2014, at 02:23, David Taylor david.tay...@speedcast.com wrote: I just recently updated one of our test servers from CentOS 6.5 to CentOS 6.6, after which I noticed that IPA logons were no longer available. From what I can see the upgrade includes quite a few changes with regard to sssd. - NTP is up and synced on the Auth servers and the client. - DNS is working to the IPA servers - I can do a kinit for users with no problem - I have uninstalled the ipa client, deleted the host profile on the IPA server and one a rejoin. The rejoin worked but the problem is the same. Software versions using - rpm -qa | grep -i ipa - rpm -qa | grep -i sssd Software versions before: libipa_hbac-1.9.2-129.el6_5.4.x86_64 device-mapper-multipath-0.4.9-72.el6_5.4.x86_64 libipa_hbac-python-1.9.2-129.el6_5.4.x86_64 ipa-python-3.0.0-37.el6.x86_64 ipa-client-3.0.0-37.el6.x86_64 device-mapper-multipath-libs-0.4.9-72.el6_5.4.x86_64 sssd-1.9.2-129.el6_5.4.x86_64 sssd-client-1.9.2-129.el6_5.4.x86_64 Software version after: sssd-ipa-1.11.6-30.el6.x86_64 libipa_hbac-1.11.6-30.el6.x86_64 device-mapper-multipath-libs-0.4.9-80.el6.x86_64 ipa-client-3.0.0-42.el6.centos.x86_64 libipa_hbac-python-1.11.6-30.el6.x86_64 ipa-python-3.0.0-42.el6.centos.x86_64 device-mapper-multipath-0.4.9-80.el6.x86_64 sssd-ldap-1.11.6-30.el6.x86_64 sssd-ad-1.11.6-30.el6.x86_64 python-sssdconfig-1.11.6-30.el6.noarch sssd-client-1.11.6-30.el6.x86_64 sssd-krb5-common-1.11.6-30.el6.x86_64 sssd-ipa-1.11.6-30.el6.x86_64 sssd-common-1.11.6-30.el6.x86_64 sssd-proxy-1.11.6-30.el6.x86_64 sssd-common-pac-1.11.6-30.el6.x86_64 sssd-krb5-1.11.6-30.el6.x86_64 sssd-1.11.6-30.el6.x86_64 The /var/log/secure logs show the following Oct 31 10:38:30 test01 sshd[2790]: Invalid user dtaylor from ip removed Oct 31 10:38:30 test01 sshd[2791]: input_userauth_request: invalid user dtaylor Oct 31 10:38:30 test01 sshd[2790]: pam_unix(sshd:auth): check pass; user unknown Oct 31 10:38:30 test01 sshd[2790]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=host removed Oct 31 10:38:30 test01 sshd[2790]: pam_succeed_if(sshd:auth): error retrieving information about user dtaylor Do you also see pam_sss being mentioned at all in your /var/log/secure at all? Can you paste your PAM configuration? It’s expected that pam_unix fails to find the IPA user, but I would also expect the PAM stack to ask pam_sss next... The /var/log/audit/audit.log logs show the following type=CRYPTO_KEY_USER msg=audit(1414715857.270:107): user pid=5831 uid=0 auid=0 ses=1 msg='op=destroy kind=server fp=5e:ee:58:a2:25:ec:16:3e:8c:61:01:e6:de:76:3d:32 direction=? spid=5831 suid=0 exe=/usr/sbin/sshd hostname=? addr=ip removed terminal=? res=success' type=CRYPTO_KEY_USER msg=audit(1414715857.270:108): user pid=5831 uid=0 auid=0 ses=1 msg='op=destroy kind=server fp=d0:6f:2f:5f:49:44:94:f2:b2:4e:15:43:69:89:9c:1d direction=? spid=5831 suid=0 exe=/usr/sbin/sshd hostname=? addr=ip removed terminal=? res=success' type=CRYPTO_SESSION msg=audit(1414715857.272:109): user pid=5830 uid=0 auid=0 ses=1 msg='op=start direction=from-client cipher=aes256-ctr ksize=256 spid=5831 suid=74 rport=44361 laddr=Client ip removed lport=22 exe=/usr/sbin/sshd hostname=? addr=ip removed terminal=? res=success' type=CRYPTO_SESSION msg=audit(1414715857.272:110): user pid=5830 uid=0 auid=0 ses=1 msg='op=start direction=from-server cipher=aes256-ctr ksize=256 spid=5831 suid=74 rport=44361 laddr=Client ip removed lport=22 exe=/usr/sbin/sshd hostname=? addr=ip removed terminal=? res=success' type=USER_LOGIN msg=audit(1414715857.310:111): user pid=5830 uid=0 auid=0 ses=1 msg='op=login acct=28756E6B6E6F776E207573657229 exe=/usr/sbin/sshd hostname=? addr=ip removed terminal=ssh res=failed' type=USER_AUTH msg=audit(1414715859.211:112): user pid=5830 uid=0 auid=0 ses=1 msg='op=PAM:authentication acct=? exe=/usr/sbin/sshd hostname=hostname removed addr=ip removed terminal=ssh res=failed' type=USER_AUTH msg=audit(1414715859.212:113): user pid=5830 uid=0 auid=0 ses=1 msg='op=password acct=28696E76616C6964207573657229 exe=/usr/sbin/sshd hostname=? addr=ip removed terminal=ssh res=failed' type=CRYPTO_KEY_USER msg=audit(1414715862.076:114): user pid=5830 uid=0 auid=0 ses=1 msg='op=destroy kind=session fp=? direction=both spid=5831 suid=74 rport=44361 laddr=Client ip removed lport=22 exe=/usr/sbin/sshd hostname=? addr=ip removed terminal=? res=success' type=CRYPTO_KEY_USER msg=audit(1414715862.078:115): user pid=5830 uid=0 auid=0 ses=1 msg='op=destroy kind=server fp=5e:ee:58:a2:25:ec:16:3e:8c:61:01:e6:de:76:3d:32 direction=? spid=5830 suid=0 exe=/usr/sbin/sshd hostname=? addr=ip removed terminal=? res=success' type=CRYPTO_KEY_USER msg=audit(1414715862.079:116): user pid=5830 uid=0 auid=0 ses=1 msg='op=destroy
Re: [Freeipa-users] [SOLVED] IPA DNS response issue
On 19.3.2014 15:12, David wrote: On Wed, Mar 19, 2014 at 01:57:24PM +0100, Petr Spacek wrote: On 18.3.2014 15:26, David wrote: We have an installation of FreeIPA (through CentOS 6.5) that's exhibiting some odd behavior with respect to serving DNS. Periodically (interval at random) named running on a replica will stop serving requests from the LDAP server but continue to respond with recursive requests. This type of failure causes us problems, as you could imagine. (It doesn't fail cleanly so it won't request from another server.) We've adjusted the amount of connections each named makes to 389, but it doesn't seem to make a difference. We're not seeing anything in the logs so troubleshooting this is becoming a bit of a (high-visibility) puzzle to us. I do happen to have a core file that I grabbed last night before sending a SIGKILL to named and restarting. (A SIGTERM has no effect.) Hopefully there's an easy answer here that we can get rolled into the environment quickly. FreeIPA has treated us extraordinarily well so far! snip Note that David (I guess :-) added logs to the ticket https://fedorahosted.org/bind-dyndb-ldap/ticket/131 and I'm looking into it. Actually, that's not me! I don't have anywhere near as much logging... At least I'm not alone... Our failures also seem to happen around log rotation time. The Kerberos ticket expiring is interesting. I'll poke around on my installation and see what I see on this side. If you need any other information, please let me know. FYI the problem was discovered fixed a while ago but I did not sent reply to you. It was fixed in all maintained branches (v2+) of bind-dyndb-ldap. All supported versions of Fedora were patched so it should not happen again. You can watch RHEL status on: RHEL 6.y: https://bugzilla.redhat.com/show_bug.cgi?id=1142176 https://bugzilla.redhat.com/show_bug.cgi?id=1142152 RHEL 7.y: https://bugzilla.redhat.com/show_bug.cgi?id=1142150 Have a nice day! -- Petr^2 Spacek -- 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] DNS forwarders in 4.1.0
Hello , I've been trying to install freeipa server v 4.1.0 on my fedora 20 machine and I can't complete the installation because of hte DNS forwarders my machine's IP is 192.168.254.7 and I'm using the same IP for DNS forwarders, this is what I did when I was installing 4.0.3 and 3.3.5 and it installed smoothly , so my question is why won't it work in 4.1.0 ? is there something new when configuring DNS forwarders? -- 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 forwarders in 4.1.0
On 31.10.2014 04:38, Rolf Nufable wrote: Hello , I've been trying to install freeipa server v 4.1.0 on my fedora 20 machine and I can't complete the installation because of hte DNS forwarders What exactly is the problem/symptom? Are you receiving an error? Or something else? We need to see exact package versions, parameters you have used, messages, logs etc. my machine's IP is 192.168.254.7 and I'm using the same IP for DNS forwarders, this is what I did when I was installing 4.0.3 and 3.3.5 and it installed smoothly , so my question is why won't it work in 4.1.0 ? is there something new when configuring DNS forwarders? I'm not sure I understand you. What do you mean with 'my machine'? Is it the (to-be-installed) IPA server? Or some other machine? Are you installing IPA with or without DNS? There is no point in configuring IPA to use itself as forwarder. Please tell us what exactly doesn't work for you :-) -- Petr^2 Spacek -- 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] Extra attributes for sync agreement AD to FreeIPA
Hello freeipa Users, I am working on a sync agreement between AD server - FreeIPA server (fedora 20) I follow the documentation, my sync works beetwen AD - FreeIPA with ipa-replica-manage connect --winsync ... However, I would like to extract attributes from my AD like : - uidNumber - gidNumber - unixHomeDirectory - loginShell - msSFU30NisDomain My AD server is 2008 R2 with with Subsystem for UNIX-based Applications. I would like rerieve these attributes in my freeipa server after sync. I had a look on google, and find informations like this : https://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/managing-sync-agmt.html#tab.sync-agmt-attrs But I did not succeed with it. May someone help me ? -- 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] Extra attributes for sync agreement AD to FreeIPA
Edouard Guigné wrote: Hello freeipa Users, I am working on a sync agreement between AD server - FreeIPA server (fedora 20) I follow the documentation, my sync works beetwen AD - FreeIPA with ipa-replica-manage connect --winsync ... However, I would like to extract attributes from my AD like : - uidNumber - gidNumber - unixHomeDirectory - loginShell - msSFU30NisDomain My AD server is 2008 R2 with with Subsystem for UNIX-based Applications. I would like rerieve these attributes in my freeipa server after sync. I had a look on google, and find informations like this : https://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/managing-sync-agmt.html#tab.sync-agmt-attrs But I did not succeed with it. May someone help me ? It should already work: http://www.port389.org/docs/389ds/design/winsync-posix.html 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] Replication fails after CentOS 6.5 - 6.6 Upgrade - sasl_io_recv failed to decode packet for connection xxxx
Hello, I just did a 'yum update' from CentOS 6.5 - 6.6 on my freeipa system (master and 2 replicas) and I seen to have run into the following bug, https://bugzilla.redhat.com/show_bug.cgi?id=953653 On Master: [root@srv-1 slapd-CN-LOCAL]# rpm -qa|grep ipa ipa-client-3.0.0-42.el6.centos.x86_64 libipa_hbac-python-1.11.6-30.el6.x86_64 python-iniparse-0.3.1-2.1.el6.noarch ipa-python-3.0.0-42.el6.centos.x86_64 sssd-ipa-1.11.6-30.el6.x86_64 ipa-server-3.0.0-42.el6.centos.x86_64 ipa-server-selinux-3.0.0-42.el6.centos.x86_64 libipa_hbac-1.11.6-30.el6.x86_64 ipa-admintools-3.0.0-42.el6.centos.x86_64 ipa-pki-common-theme-9.0.3-7.el6.noarch ipa-pki-ca-theme-9.0.3-7.el6.noarch [root@srv-1 slapd-CN-LOCAL]# rpm -qa|grep 389 389-ds-base-1.2.11.15-47.el6.x86_64 389-ds-base-libs-1.2.11.15-47.el6.x86_64 ldapsearch -b cn=config -D cn=Directory Manager -W | grep nsslapd-sasl-max-buffer-size nsslapd-sasl-max-buffer-size: 65536 [root@srv-1]tail /etc/dirsrv/slapd-/errors [31/Oct/2014:10:59:51 -0400] - sasl_io_recv failed to decode packet for connection 2313 [31/Oct/2014:10:59:55 -0400] - sasl_io_recv failed to decode packet for connection 2314 [31/Oct/2014:11:00:00 -0400] - sasl_io_recv failed to decode packet for connection 2316 [31/Oct/2014:11:00:01 -0400] - sasl_io_recv failed to decode packet for connection 2315 On Replica: [root@srv-2 slapd-CN-LOCAL]# rpm -qa|grep ipa ipa-server-selinux-3.0.0-42.el6.centos.x86_64 libipa_hbac-1.11.6-30.el6.x86_64 ipa-admintools-3.0.0-42.el6.centos.x86_64 python-iniparse-0.3.1-2.1.el6.noarch ipa-pki-common-theme-9.0.3-7.el6.noarch ipa-server-3.0.0-42.el6.centos.x86_64 ipa-client-3.0.0-42.el6.centos.x86_64 ipa-pki-ca-theme-9.0.3-7.el6.noarch libipa_hbac-python-1.11.6-30.el6.x86_64 ipa-python-3.0.0-42.el6.centos.x86_64 sssd-ipa-1.11.6-30.el6.x86_64 [root@srv-2 slapd-CN-LOCAL]# rpm -qa|grep 389 389-ds-base-1.2.11.15-47.el6.x86_64 389-ds-base-libs-1.2.11.15-47.el6.x86_64 [root@srv-2 slapd-CN-LOCAL]# ldapsearch -b cn=config -D cn=Directory Manager -W | grep nsslapd-sasl-max-buffer-size Enter LDAP Password: nsslapd-sasl-max-buffer-size: 65536 [root@svr-2]tail -f /etc/dirsrv/slapd-/errors [31/Oct/2014:11:01:11 -0400] NSMMReplicationPlugin - agmt=cn=meTosrv-1. (srv-1:389): Replication bind with GSSAPI auth resumed [31/Oct/2014:11:01:18 -0400] NSMMReplicationPlugin - agmt=cn=meTosrv-1. (srv-1:389): Warning: unable to replicate schema: rc=2 [31/Oct/2014:11:01:18 -0400] NSMMReplicationPlugin - agmt=cn=meTosrv-1. (srv-1:389): Consumer failed to replay change (uniqueid (null), CSN (null)): Can't contact LDAP server(-1). Will retry later. [31/Oct/2014:11:01:18 -0400] NSMMReplicationPlugin - agmt=cn=meTosrv-1. (srv-1:389): Failed to send update operation to consumer (uniqueid 515cdb0f-24fa11e2-816add07-a91dabe7, CSN 5453fc2600090003): Can't contact LDAP server. Will retry later. [31/Oct/2014:11:01:18 -0400] NSMMReplicationPlugin - agmt=cn=meTosrv-1. (srv-1:389): Warning: unable to send endReplication extended operation (Can't contact LDAP server) In the ticket, Scott Poore says he increased the nsslapd-sasl-max-buffer-size to work around the problem. Is this the correct course of action, or should I be trying something else? Thanks, Mike -- 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] strange error from EL 7 install?
On Mon, Oct 13, 2014 at 10:08:55PM -0700, Janelle wrote: Actually, I did find a fix and forgot to post. I was able to mirror the COPR repo, and after reviewing it, found that simply removing the pki-base...fc21 directory, and regenning the repo data with createrepo, fixed the problem. It drops the version of PKI back to the 10.1 branch and that resolved the dependencies. Hope this helps, Janelle You don't need to mirror the repo for that simply using yum-plugin-versionlock would be sufficient, unfortunatly now that solution does not work any more since the freeipa-server package depends on pki-ca = 10.2.0-3 wich in turn depends on the 10.2.x pki-server and pki-base packages. I checked out what it would take to backport jackson-jaxrs-json-provider to CentOS 7 and this is quite a task. The fedora 21 packages build up a dependency chain wich includes aspectjweaver, eclipselink, springframework and some more stuff Does mkosek offer a repo with older builds wich are considered working? Chris -- 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] Extra attributes for sync agreement AD to FreeIPA
Edouard Guigné wrote: Hello Rob, Thank you for your answer. Do you mean it should already work ? Or I have to do this on the FreeIPA server : |rm /etc/dirsrv/slapd-INSTNAME/schema/10rfc2307.ldif cp /usr/share/dirsrv/data/10rfc2307bis.ldif /etc/dirsrv/slapd-INSTNAME/schema Sorry, I guess I was a little terse. The nisDomain is already defined for IPA so you can skip that bit. The Posix Winsync Plugin is disabled by default. You'll need to enable it and configure it to match your environment. See the wiki page for configuration details. You can either enable and configure it online by using ldapmodify and binding as the Directory Manager or by shutting down 389-ds and modifying dse.ldif, then restarting it (or use a tool like Apache Directory Studio). rob | Best Regards, have a nice we. Ed Le 31/10/2014 16:04, Rob Crittenden a écrit : Edouard Guigné wrote: Hello freeipa Users, I am working on a sync agreement between AD server - FreeIPA server (fedora 20) I follow the documentation, my sync works beetwen AD - FreeIPA with ipa-replica-manage connect --winsync ... However, I would like to extract attributes from my AD like : - uidNumber - gidNumber - unixHomeDirectory - loginShell - msSFU30NisDomain My AD server is 2008 R2 with with Subsystem for UNIX-based Applications. I would like rerieve these attributes in my freeipa server after sync. I had a look on google, and find informations like this : https://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/managing-sync-agmt.html#tab.sync-agmt-attrs But I did not succeed with it. May someone help me ? It should already work: http://www.port389.org/docs/389ds/design/winsync-posix.html rob -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Replication fails after CentOS 6.5 - 6.6 Upgrade - sasl_io_recv failed to decode packet for connection xxxx
Craig White System Administrator O 623-201-8179 M 602-377-9752 SkyTouch Technology 4225 E. Windrose Dr. Phoenix, AZ 85032 -Original Message- From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Michael Mercier Sent: Friday, October 31, 2014 8:12 AM To: freeipa-users@redhat.com Subject: [Freeipa-users] Replication fails after CentOS 6.5 - 6.6 Upgrade - sasl_io_recv failed to decode packet for connection Hello, I just did a 'yum update' from CentOS 6.5 - 6.6 on my freeipa system (master and 2 replicas) and I seen to have run into the following bug, https://bugzilla.redhat.com/show_bug.cgi?id=953653 On Master: [root@srv-1 slapd-CN-LOCAL]# rpm -qa|grep ipa ipa-client-3.0.0-42.el6.centos.x86_64 libipa_hbac-python-1.11.6-30.el6.x86_64 python-iniparse-0.3.1-2.1.el6.noarch ipa-python-3.0.0-42.el6.centos.x86_64 sssd-ipa-1.11.6-30.el6.x86_64 ipa-server-3.0.0-42.el6.centos.x86_64 ipa-server-selinux-3.0.0-42.el6.centos.x86_64 libipa_hbac-1.11.6-30.el6.x86_64 ipa-admintools-3.0.0-42.el6.centos.x86_64 ipa-pki-common-theme-9.0.3-7.el6.noarch ipa-pki-ca-theme-9.0.3-7.el6.noarch [root@srv-1 slapd-CN-LOCAL]# rpm -qa|grep 389 389-ds-base-1.2.11.15-47.el6.x86_64 389-ds-base-libs-1.2.11.15-47.el6.x86_64 ldapsearch -b cn=config -D cn=Directory Manager -W | grep nsslapd-sasl-max-buffer-size nsslapd-sasl-max-buffer-size: 65536 [root@srv-1]tail /etc/dirsrv/slapd-/errors [31/Oct/2014:10:59:51 -0400] - sasl_io_recv failed to decode packet for connection 2313 [31/Oct/2014:10:59:55 -0400] - sasl_io_recv failed to decode packet for connection 2314 [31/Oct/2014:11:00:00 -0400] - sasl_io_recv failed to decode packet for connection 2316 [31/Oct/2014:11:00:01 -0400] - sasl_io_recv failed to decode packet for connection 2315 On Replica: [root@srv-2 slapd-CN-LOCAL]# rpm -qa|grep ipa ipa-server-selinux-3.0.0-42.el6.centos.x86_64 libipa_hbac-1.11.6-30.el6.x86_64 ipa-admintools-3.0.0-42.el6.centos.x86_64 python-iniparse-0.3.1-2.1.el6.noarch ipa-pki-common-theme-9.0.3-7.el6.noarch ipa-server-3.0.0-42.el6.centos.x86_64 ipa-client-3.0.0-42.el6.centos.x86_64 ipa-pki-ca-theme-9.0.3-7.el6.noarch libipa_hbac-python-1.11.6-30.el6.x86_64 ipa-python-3.0.0-42.el6.centos.x86_64 sssd-ipa-1.11.6-30.el6.x86_64 [root@srv-2 slapd-CN-LOCAL]# rpm -qa|grep 389 389-ds-base-1.2.11.15-47.el6.x86_64 389-ds-base-libs-1.2.11.15-47.el6.x86_64 [root@srv-2 slapd-CN-LOCAL]# ldapsearch -b cn=config -D cn=Directory Manager -W | grep nsslapd-sasl-max-buffer-size Enter LDAP Password: nsslapd-sasl-max-buffer-size: 65536 [root@svr-2]tail -f /etc/dirsrv/slapd-/errors [31/Oct/2014:11:01:11 -0400] NSMMReplicationPlugin - agmt=cn=meTosrv-1. (srv-1:389): Replication bind with GSSAPI auth resumed [31/Oct/2014:11:01:18 -0400] NSMMReplicationPlugin - agmt=cn=meTosrv-1. (srv-1:389): Warning: unable to replicate schema: rc=2 [31/Oct/2014:11:01:18 -0400] NSMMReplicationPlugin - agmt=cn=meTosrv-1. (srv-1:389): Consumer failed to replay change (uniqueid (null), CSN (null)): Can't contact LDAP server(-1). Will retry later. [31/Oct/2014:11:01:18 -0400] NSMMReplicationPlugin - agmt=cn=meTosrv-1. (srv-1:389): Failed to send update operation to consumer (uniqueid 515cdb0f-24fa11e2-816add07-a91dabe7, CSN 5453fc2600090003): Can't contact LDAP server. Will retry later. [31/Oct/2014:11:01:18 -0400] NSMMReplicationPlugin - agmt=cn=meTosrv-1. (srv-1:389): Warning: unable to send endReplication extended operation (Can't contact LDAP server) In the ticket, Scott Poore says he increased the nsslapd-sasl-max-buffer-size to work around the problem. Is this the correct course of action, or should I be trying something else? I can't speak with certainty but I can tell you that increasing the buffer solved my replication problem immediately. Craig -- 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 forwarders in 4.1.0
On 10/31/2014 10:42 AM, Petr Spacek wrote: On 31.10.2014 04:38, Rolf Nufable wrote: Hello , I've been trying to install freeipa server v 4.1.0 on my fedora 20 machine and I can't complete the installation because of hte DNS forwarders What exactly is the problem/symptom? Are you receiving an error? Or something else? We need to see exact package versions, parameters you have used, messages, logs etc. my machine's IP is 192.168.254.7 and I'm using the same IP for DNS forwarders, this is what I did when I was installing 4.0.3 and 3.3.5 and it installed smoothly , so my question is why won't it work in 4.1.0 ? is there something new when configuring DNS forwarders? I'm not sure I understand you. What do you mean with 'my machine'? Is it the (to-be-installed) IPA server? Or some other machine? Are you installing IPA with or without DNS? There is no point in configuring IPA to use itself as forwarder. Please tell us what exactly doesn't work for you :-) And back to your original question: 4.1 has a lot of changes related to DNSSEC work so something might be broken and we like to understand what and why. -- 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] Extra attributes for sync agreement AD to FreeIPA
On 10/31/2014 11:49 AM, Rob Crittenden wrote: Edouard Guigné wrote: Hello Rob, Thank you for your answer. Do you mean it should already work ? Or I have to do this on the FreeIPA server : |rm /etc/dirsrv/slapd-INSTNAME/schema/10rfc2307.ldif cp /usr/share/dirsrv/data/10rfc2307bis.ldif /etc/dirsrv/slapd-INSTNAME/schema Sorry, I guess I was a little terse. The nisDomain is already defined for IPA so you can skip that bit. The Posix Winsync Plugin is disabled by default. You'll need to enable it and configure it to match your environment. See the wiki page for configuration details. You can either enable and configure it online by using ldapmodify and binding as the Directory Manager or by shutting down 389-ds and modifying dse.ldif, then restarting it (or use a tool like Apache Directory Studio). rob | Best Regards, have a nice we. Ed Le 31/10/2014 16:04, Rob Crittenden a écrit : Edouard Guigné wrote: Hello freeipa Users, I am working on a sync agreement between AD server - FreeIPA server (fedora 20) I follow the documentation, my sync works beetwen AD - FreeIPA with ipa-replica-manage connect --winsync ... However, I would like to extract attributes from my AD like : - uidNumber - gidNumber - unixHomeDirectory - loginShell - msSFU30NisDomain My AD server is 2008 R2 with with Subsystem for UNIX-based Applications. I would like rerieve these attributes in my freeipa server after sync. I had a look on google, and find informations like this : https://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/managing-sync-agmt.html#tab.sync-agmt-attrs But I did not succeed with it. May someone help me ? It should already work: http://www.port389.org/docs/389ds/design/winsync-posix.html rob I just want to mention that this is not a recommended approach. While the plugin exists in DS it is not enabled or supported for IPA. The supported way to deal with POSIX attribute in AD is to use trust with AD rather than sync. Is this a one time move of the accounts from AD to IPA and you plan to turn the plugin off after initial sync? If not it will be a configuration we would recommend. If you just want to copy attributes using ipa migrate-ds or dumping accounts into LDIF and then loading LDIF would be a better option. -- 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] Errors upgrading 4.0.1 to 4.1
Thank you!!! That was exactly it. * Removed the nsEncryptionConfig entry from 99user.ldif * Re-run the ipa-ldap-update --upgrade * Then ipa-dns-install and things are looking much better - both servers are now back up and running. What is the lesson here (besides have good backups)? Should we be turning off ALL servers before upgrading to prevent replication? I did notice that the 99user entry was made it to BOTH servers, which makes me think that replication is not exactly the culprit. -M On 10/31/14, 1:30 AM, Ludwig Krispenz wrote: On 10/30/2014 07:36 PM, Martin Basti wrote: On 30/10/14 19:18, Michael Lasevich wrote: Makes sense. What is the solution here? I have the latest 389-ds installed but still getting allowWeakCipher error - how to I get around that? -M Sorry I don't know, I CCied Ludwig, he is DS guru. I already asked to verify the schema files: can you check your schema files for the definition of the nsEncryptionConfig objectclass, it should be only in 01core389.ldif and contain allowWeakCipher, but it could have been added also to 99user.ldif during replication when schema changes have been consolidated and what is the latest ds version you are using: rpm -q 389-ds-base Martin^2 On 10/30/14, 11:12 AM, Martin Basti wrote: On 24/10/14 05:17, Michael Lasevich wrote: While upgrading from 4.0.1. to 4.1 on fedora 20 got following on one of the two boxes: Upgrade failed with attribute allowWeakCipher not allowed IPA upgrade failed. Unexpected error DuplicateEntry: This entry already exists Named errors are caused by cascade effect, if ldap schema and entry updates failed, there is misconfigured DS plugin which is responsible to keep DNSSEC keys DN unique, what causes duplication errors. DuplicateEntry exception is fatal, so dnskeysyncd installation will not continue, what causes there are not appropriate permissions for token database, and named-pkcs11 can't read tokens. It seems the ipa no longer starts up after this. The replica server seems to have had same error,but it runs just fine. From digging around, it appears that there are a number of GSS errors in dirsrv and bind fails with something like: named-pkcs11[2212]: ObjectStore.cpp(74): Failed to open token e919db16-6329-406c-6ae4-120ad68508c4 named-pkcs11[2212]: sha1.c:92: fatal error: named-pkcs11[2212]: RUNTIME_CHECK(pk11_get_session(ctx, OP_DIGEST, isc_boolean_true, isc_boolean_false, isc_boolean_false, ((void *)0), 0) == 0) failed Any help would be appreciated -M -- Martin Basti -- 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
[Freeipa-users] IPA Backup in AWS - best practices?
What is the current best practice for backing up IPA servers? Especially in AWS? Given AWS strengths and weaknesses, I would love to be able to move all of IPA data/state onto a separate drive and just snapshot it on regular basis - but it seems that IPA data is all over the place, so it is hard to separate it from the rest of the OS. Snapshotting entire root drive is another option, but restoring from that is a bit of a pain, so it may not be optimal. There is always also the plain old tar it all up approach. What do people use? What works, what does not? Thanks, -M -- 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] IPA Backup in AWS - best practices?
On 10/31/2014 05:42 PM, Michael Lasevich wrote: What is the current best practice for backing up IPA servers? Especially in AWS? Given AWS strengths and weaknesses, I would love to be able to move all of IPA data/state onto a separate drive and just snapshot it on regular basis - but it seems that IPA data is all over the place, so it is hard to separate it from the rest of the OS. Snapshotting entire root drive is another option, but restoring from that is a bit of a pain, so it may not be optimal. There is always also the plain old tar it all up http://www.freeipa.org/page/Backup_and_Restore This is pretty much what we recommended for some time until we built: http://www.freeipa.org/page/V3/Backup_and_Restore approach. What do people use? What works, what does not? Thanks, -M -- 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
