Re: [Freeipa-users] F20 Problem upgrading to 4.1
On 30/10/14 06:09, Michael Lasevich wrote: Maybe I should not be doing this late at night, but I cannot find cn=IPK11 Unique IDs,cn=IPA UUID,cn=plugins,cn=config anywhere. -M IMO something bad happens during the ipa upgrade, can you remove ipk11UniqueId=autogenerate,cn=keys,cn=sec,cn=dns,dc=my,dc=domain,dc=com entry, and run ipa-ldap-updater --upgrade, then reinstall DNS (rerun ipa-dns-install) Let me know if it works. On 10/29/14, 3:03 AM, Martin Basti wrote: On 28/10/14 20:54, Michael Lasevich wrote: I have a pair of servers that were both installed on clean Fedora20 4.0.1 from pviktori copr repo and then upgraded from mkosek to 4.1 During update, secondary was done first and worked but primary run into trouble as described Looking under cn=keys,cn=sec,cn=dns,dc=my,dc=domain,dc=com I get one entry with dn: ipk11UniqueId=autogenerate,cn=keys,cn=sec,cn=dns,dc=my,dc=domain,dc=com Not sure what of that you need there, but for ipk11Label it has: dnssec-replica:infra-dc-02.my.domain.com. (which is the replica that IS working) Thanks, -M On 10/28/14, 3:21 AM, Martin Basti wrote: On 28/10/14 06:14, Michael Lasevich wrote: Running into same thing, but running ipa-dnsinstall does not complete: = Configuring DNS (named) [1/8]: generating rndc key file WARNING: Your system is running out of entropy, you may experience long delays [2/8]: setting up our own record [3/8]: adding NS record to the zones [4/8]: setting up CA record [5/8]: setting up kerberos principal [6/8]: setting up named.conf [7/8]: configuring named to start on boot [8/8]: changing resolv.conf to point to ourselves Done configuring DNS (named). Configuring DNS key synchronization service (ipa-dnskeysyncd) [1/6]: checking status [2/6]: setting up kerberos principal [3/6]: setting up SoftHSM [4/6]: adding DNSSEC containers [5/6]: creating replica keys [error] DuplicateEntry: This entry already exists Unexpected error - see /var/log/ipaserver-install.log for details: DuplicateEntry: This entry already exists = Looking into the /var/log/ipaserver-install.log gets: = 2014-10-28T05:01:24Z DEBUG Storing replica public key to LDAP, ipk11UniqueId=autogenerate,cn=keys,cn=sec,cn=dns,dc=my,dc=domain,dc=com 2014-10-28T05:01:24Z DEBUG flushing ldap://infra-dc-01.my.domain.com:389 from SchemaCache 2014-10-28T05:01:24Z DEBUG retrieving schema for SchemaCache url=ldap://infra-dc-01.my.domain.com:389 conn=ldap.ldapobject.SimpleLDAPObject instance at 0x47d0d88 2014-10-28T05:01:24Z DEBUG Traceback (most recent call last): File /usr/lib/python2.7/site-packages/ipaserver/install/service.py, line 382, in start_creation run_step(full_msg, method) File /usr/lib/python2.7/site-packages/ipaserver/install/service.py, line 372, in run_step method() File /usr/lib/python2.7/site-packages/ipaserver/install/dnskeysyncinstance.py, line 340, in __setup_replica_keys ldap.add_entry(entry) File /usr/lib/python2.7/site-packages/ipapython/ipaldap.py, line 1592, in add_entry self.conn.add_s(entry.dn, attrs.items()) File /usr/lib64/python2.7/contextlib.py, line 35, in __exit__ self.gen.throw(type, value, traceback) File /usr/lib/python2.7/site-packages/ipapython/ipaldap.py, line 1169, in error_handler raise errors.DuplicateEntry() DuplicateEntry: This entry already exists 2014-10-28T05:01:24Z DEBUG [error] DuplicateEntry: This entry already exists 2014-10-28T05:01:24Z DEBUG File /usr/lib/python2.7/site-packages/ipaserver/install/installutils.py, line 646, in run_script return_value = main_function() File /sbin/ipa-dns-install, line 218, in main dnskeysyncd.create_instance(api.env.host, api.env.realm) File /usr/lib/python2.7/site-packages/ipaserver/install/dnskeysyncinstance.py, line 128, in create_instance self.start_creation() File /usr/lib/python2.7/site-packages/ipaserver/install/service.py, line 382, in start_creation run_step(full_msg, method) File /usr/lib/python2.7/site-packages/ipaserver/install/service.py, line 372, in run_step method() File /usr/lib/python2.7/site-packages/ipaserver/install/dnskeysyncinstance.py, line 340, in __setup_replica_keys ldap.add_entry(entry) File /usr/lib/python2.7/site-packages/ipapython/ipaldap.py, line 1592, in add_entry self.conn.add_s(entry.dn, attrs.items()) File /usr/lib64/python2.7/contextlib.py, line 35, in __exit__ self.gen.throw(type, value, traceback) File /usr/lib/python2.7/site-packages/ipapython/ipaldap.py, line 1169, in error_handler raise errors.DuplicateEntry() 2014-10-28T05:01:24Z DEBUG The ipa-dns-install command failed, exception: DuplicateEntry: This entry already exists Hello Michael, can you send me which entries do you have in cn=keys,cn=sec,cn=dns,dc=my,dc=domain,dc=com, it looks like directory server doesn't generate uniqueID for keys. Do you have upgraded IPA or fresh installed? Martin^2
[Freeipa-users] adding trust relationships
Hi, I have ipa master server: A and I have 2 ipa replicas: B and C replica B crashed, so it was deleted from A and recreated using ipa-replica-parepare to generate the file and set it up from there. in server A B and C, if I do ipa-replica-manage list serverA lists A B and C as master serverB lists A B and C as master serverC lists only A and C as master .. B is missing. trying the command ipa-replica-manage connect B from serverC gives: You cannot connect to a previously deleted master now how do I add trust relationship between C and B ? Thanks, Shashi -- 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] adding replication agreements
Shashi Dahal wrote: Hi, I have ipa master server: A and I have 2 ipa replicas: B and C replica B crashed, so it was deleted from A and recreated using ipa-replica-parepare to generate the file and set it up from there. in server A B and C, if I do ipa-replica-manage list serverA lists A B and C as master serverB lists A B and C as master serverC lists only A and C as master .. B is missing. trying the command ipa-replica-manage connect B from serverC gives: You cannot connect to a previously deleted master now how do I add trust relationship between C and B ? I changed the subject as this isn't trust, it's replication. I don't want to be pedantic but there is a significant difference. What I'd do, on each master, is this: ipa-replica-manage list -v `hostname` I think you'll find that C isn't getting updates. The masters list is stored in LDAP so if C doesn't know that B exists it likely means that its data is stale. 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] IPA Server 4.* error on Centos7
Hello for all, I'm trying to install the IPA Server version 4.* on CentOS 7 using the EPEL 7 and the MKOSEK FreeIPA Repo (for 4.* version). But this is giving me a package dependency error. After a search i found this Thread ( https://www.redhat.com/archives/freeipa-users/2014-October/msg00200.html) wit the same error but without a good fix i think, it is possible that we contact someone to fix this issue? I really apreciate installing the 4.* version instead of 3.* of FreeIPA on my production environment if there is a way to fix this. 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
Re: [Freeipa-users] F20 Problem upgrading to 4.1
*sigh* Feel like I am going around in circles ipa-ldap-updater --upgrade failed with: Upgrade failed with attribute allowWeakCipher not allowed I am running 1.3.3 from mkosek-freeipa copr: 389-ds-base-libs-1.3.3.5-1.fc20.x86_64 389-ds-base-1.3.3.5-1.fc20.x86_64 yum info 389-ds-base Loaded plugins: copr Installed Packages Name: 389-ds-base Arch: x86_64 Version : 1.3.3.5 Release : 1.fc20 Size: 5.2 M Repo: installed From repo : mkosek-freeipa Summary : 389 Directory Server (base) URL : http://port389.org/ License : GPLv2 with exceptions Description : 389 Directory Server is an LDAPv3 compliant server. The base package includes : the LDAP server and command line utilities for server administration. -M On 10/30/14, 1:44 AM, Martin Basti wrote: On 30/10/14 06:09, Michael Lasevich wrote: Maybe I should not be doing this late at night, but I cannot find cn=IPK11 Unique IDs,cn=IPA UUID,cn=plugins,cn=config anywhere. -M IMO something bad happens during the ipa upgrade, can you remove ipk11UniqueId=autogenerate,cn=keys,cn=sec,cn=dns,dc=my,dc=domain,dc=com entry, and run ipa-ldap-updater --upgrade, then reinstall DNS (rerun ipa-dns-install) Let me know if it works. On 10/29/14, 3:03 AM, Martin Basti wrote: On 28/10/14 20:54, Michael Lasevich wrote: I have a pair of servers that were both installed on clean Fedora20 4.0.1 from pviktori copr repo and then upgraded from mkosek to 4.1 During update, secondary was done first and worked but primary run into trouble as described Looking under cn=keys,cn=sec,cn=dns,dc=my,dc=domain,dc=com I get one entry with dn: ipk11UniqueId=autogenerate,cn=keys,cn=sec,cn=dns,dc=my,dc=domain,dc=com Not sure what of that you need there, but for ipk11Label it has: dnssec-replica:infra-dc-02.my.domain.com. (which is the replica that IS working) Thanks, -M On 10/28/14, 3:21 AM, Martin Basti wrote: On 28/10/14 06:14, Michael Lasevich wrote: Running into same thing, but running ipa-dnsinstall does not complete: = Configuring DNS (named) [1/8]: generating rndc key file WARNING: Your system is running out of entropy, you may experience long delays [2/8]: setting up our own record [3/8]: adding NS record to the zones [4/8]: setting up CA record [5/8]: setting up kerberos principal [6/8]: setting up named.conf [7/8]: configuring named to start on boot [8/8]: changing resolv.conf to point to ourselves Done configuring DNS (named). Configuring DNS key synchronization service (ipa-dnskeysyncd) [1/6]: checking status [2/6]: setting up kerberos principal [3/6]: setting up SoftHSM [4/6]: adding DNSSEC containers [5/6]: creating replica keys [error] DuplicateEntry: This entry already exists Unexpected error - see /var/log/ipaserver-install.log for details: DuplicateEntry: This entry already exists = Looking into the /var/log/ipaserver-install.log gets: = 2014-10-28T05:01:24Z DEBUG Storing replica public key to LDAP, ipk11UniqueId=autogenerate,cn=keys,cn=sec,cn=dns,dc=my,dc=domain,dc=com 2014-10-28T05:01:24Z DEBUG flushing ldap://infra-dc-01.my.domain.com:389 from SchemaCache 2014-10-28T05:01:24Z DEBUG retrieving schema for SchemaCache url=ldap://infra-dc-01.my.domain.com:389 conn=ldap.ldapobject.SimpleLDAPObject instance at 0x47d0d88 2014-10-28T05:01:24Z DEBUG Traceback (most recent call last): File /usr/lib/python2.7/site-packages/ipaserver/install/service.py, line 382, in start_creation run_step(full_msg, method) File /usr/lib/python2.7/site-packages/ipaserver/install/service.py, line 372, in run_step method() File /usr/lib/python2.7/site-packages/ipaserver/install/dnskeysyncinstance.py, line 340, in __setup_replica_keys ldap.add_entry(entry) File /usr/lib/python2.7/site-packages/ipapython/ipaldap.py, line 1592, in add_entry self.conn.add_s(entry.dn, attrs.items()) File /usr/lib64/python2.7/contextlib.py, line 35, in __exit__ self.gen.throw(type, value, traceback) File /usr/lib/python2.7/site-packages/ipapython/ipaldap.py, line 1169, in error_handler raise errors.DuplicateEntry() DuplicateEntry: This entry already exists 2014-10-28T05:01:24Z DEBUG [error] DuplicateEntry: This entry already exists 2014-10-28T05:01:24Z DEBUG File /usr/lib/python2.7/site-packages/ipaserver/install/installutils.py, line 646, in run_script return_value = main_function() File /sbin/ipa-dns-install, line 218, in main dnskeysyncd.create_instance(api.env.host, api.env.realm) File /usr/lib/python2.7/site-packages/ipaserver/install/dnskeysyncinstance.py, line 128, in create_instance self.start_creation() File /usr/lib/python2.7/site-packages/ipaserver/install/service.py, line 382, in start_creation run_step(full_msg, method) File
Re: [Freeipa-users] Errors upgrading 4.0.1 to 4.1
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 -- 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
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 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 -- 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] Woes adding a samba server to the ipa domain
On 10/29/2014 11:38 PM, Loris Santamaria wrote: El mié, 29-10-2014 a las 20:49 -0400, Dmitri Pal escribió: On 10/29/2014 05:01 PM, Loris Santamaria wrote: El mié, 29-10-2014 a las 21:40 +0100, John Obaterspok escribió: Hello, I've tried this as well. My IPA is not connected to an AD. My smb.conf looks almost the same. The differences are: - I got the default workgroup set (MY or something) - No FILE:/ prefix for keytab file I had the samba and ipserver on the same box so I just had to add the cifs server and get keytab file in the same way. I was a bit surprised to see that accessing samba using smbclient -k \\... worked right away from a linux box. Then stopped working if I did kdestroy. But, I never got it to work from Windows. The Windows PC is not joined to any AD, it uses MIT Kerb client 4.0.1 and I successfully get tickes and can sshlogin via putty without password. Any ideas on how to get this going from Windows as well? I guess you should prepare the ipa server for a windows domain trust (even if you won't setup any trust with an ad domain), with ipa-adtrust-install. Beware that it will overwrite your smb.conf. With that configuration and the steps described in http://www.redhat.com/archives/freeipa-users/2013-September/msg00226.html you will be able to use the native windows kerberos libraries and you should be able to open a samba share with your kerberos credentials. Best regards Would by any chance you be able to create a HowTo solution on the FreeIPA wiki? Seems like it would be a simple cutpaste from couple mails. Thanks in advance! Here it is: http://www.freeipa.org/page/Howto/Integrating_a_Samba_File_Server_With_IPA Best regards Thanks! -- 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
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. 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] IPA Server 4.* error on Centos7
On 10/30/2014 12:45 PM, Lucas Diedrich wrote: Hello for all, I'm trying to install the IPA Server version 4.* on CentOS 7 using the EPEL 7 and the MKOSEK FreeIPA Repo (for 4.* version). But this is giving me a package dependency error. After a search i found this Thread (https://www.redhat.com/archives/freeipa-users/2014-October/msg00200.html) wit the same error but without a good fix i think, it is possible that we contact someone to fix this issue? I really apreciate installing the 4.* version instead of 3.* of FreeIPA on my production environment if there is a way to fix this. Thanks. There are plans to fix this soon. We want to have 4.1 work on CentOS but we need to do some heavy lifting first. Please stay tuned. -- 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
[Freeipa-users] Centos IPA Client fails after upgrade to 6.6
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 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 kind=server fp=d0:6f:2f:5f:49:44:94:f2:b2:4e:15:43:69:89:9c:1d direction=? spid=5830 suid=0 exe=/usr/sbin/sshd hostname=? addr=ip removed terminal=? res=success' type=USER_LOGIN msg=audit(1414715862.079:117): user pid=5830 uid=0 auid=0 ses=1 msg='op=login acct=28696E76616C6964207573657229 exe=/usr/sbin/sshd hostname=? addr=ip removed terminal=ssh res=failed' The /var/log/sssd/sssd_IPA Svr IP removed.log logs show the
Re: [Freeipa-users] vsftpd PAM setup problem
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 -- 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
