From sgallagh at redhat.com Mon Nov 1 11:05:22 2010 From: sgallagh at redhat.com (Stephen Gallagher) Date: Mon, 01 Nov 2010 07:05:22 -0400 Subject: [Freeipa-users] General question about FreeIPA : roaming profiles in a school? In-Reply-To: <1288426409.10341.20.camel@babasse.presbytere.montpezat> References: <1288426409.10341.20.camel@babasse.presbytere.montpezat> Message-ID: <4CCE9EF2.7030105@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/30/2010 04:13 AM, Niki Kovacs wrote: > 2) All the user data are stored centrally on the server, preferably with > quotas (for example max. 1 GB per user). > Others have commented on your other points, but I'm going to add my two cents to this one. This will be the trickiest portion to implement (nearly all of your other needs are built-in to FreeIPA). However, centrally-managed data requires some manual configuration. The classic example would be to set up a centralized NFS server providing the home directories and using automount on each client to connect to them. There are many HOWTOs and guidelines (and your friendly neighborhood RHCE would be able to guide you through this as well). For added security, NFSv4 will also allow authentication via Kerberos (provided by FreeIPA) to ensure that no one can gain access to anyone else's NFS file-share. IPAv2 will have support for centrally-managing autofs settings, but IPA v1.2 currently does not (you can do it manually with direct LDAP tools, but it might be just as easy to do with puppet-managed config files) Having a built-in mechanism for setting up NFSv4 mounted home directories (along with appropriate kerberos credentials) would be a definite advantage for FreeIPA, so I'm going to make a recommendation that we consider that for inclusion in the next version of FreeIPA (be it 2.1 or 3.0). It's too late for feature creep in 2.0, though. - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkzOnvIACgkQeiVVYja6o6NdigCgoeb4NDNH55Np5/2Tt1zW6Qul k0YAoJjSeGZ6r64UPUE15Drr4qR521uU =cq0K -----END PGP SIGNATURE----- From kambiz at mcnc.org Mon Nov 8 19:32:45 2010 From: kambiz at mcnc.org (Kambiz Aghaiepour) Date: Mon, 08 Nov 2010 14:32:45 -0500 Subject: [Freeipa-users] periodic failures on replicas ... Message-ID: <4CD8505D.9040906@mcnc.org> I'm seeing our IPA replicas periodically failing with errors of: [08/Nov/2010:08:12:02 -0500] - Not listening for new connections - too many fds open [08/Nov/2010:08:12:02 -0500] - Listening for new connections again [08/Nov/2010:08:12:02 -0500] - Not listening for new connections - too many fds open [08/Nov/2010:08:12:02 -0500] - Listening for new connections again It's not clear to me what's triggering this condition. When it happens, we're restarting services on the replica (ipactl restart), and things go back to normal for several days, until the next failure. I notice the following during "normal" running of services : NSMMReplicationPlugin - repl_set_mtn_referrals: could not set referrals for replica dc=example,dc=org: 1 (on both the consumers and provider). Is this an error I should worry about ? Kambiz -- "All tyranny needs to gain a foothold is for people of good conscience to remain silent." --Thomas Jefferson From danieljamesscott at gmail.com Mon Nov 8 20:04:39 2010 From: danieljamesscott at gmail.com (Dan Scott) Date: Mon, 8 Nov 2010 15:04:39 -0500 Subject: [Freeipa-users] Error changing expired user password using SSH Message-ID: Hi, I'm having problems with users accessing their accounts for the first time using SSH. I create their account in FreeIPA and set a (expired) password. Then I have them ssh into one of our computers to setup their password. The connection displays the following: djscott at pc35:~$ ssh guser at pc20 guser at pc20's password: Warning: Your password will expire in less than one hour. Warning: password has expired. WARNING: Your password has expired. You must change your password now and login again! Changing password for user guser. Kerberos 5 Password: Warning: Your password will expire in less than one hour. New password: Retype new password: passwd: Authentication token manipulation error Connection to pc20 closed. And the password change fails. Here is the relevant section from the Kerberos logfile. There is no entry in the LDAP log in dirsrv. Nov 08 14:48:21 fileserver2.example.com krb5kdc[1246](info): AS_REQ (7 etypes {18 17 16 23 1 3 2}) 192.168.1.20: CLIENT KEY EXPIRED: guser at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM, Password has expired Nov 08 14:48:21 fileserver2.example.com krb5kdc[1246](info): AS_REQ (7 etypes {18 17 16 23 1 3 2}) 192.168.1.20: NEEDED_PREAUTH: guser at EXAMPLE.COM for kadmin/changepw at EXAMPLE.COM, Additional pre-authentication required Nov 08 14:48:22 fileserver2.example.com krb5kdc[1246](info): AS_REQ (7 etypes {18 17 16 23 1 3 2}) 192.168.1.20: ISSUE: authtime 1289245702, etypes {rep=18 tkt=18 ses=18}, guser at EXAMPLE.COM for kadmin/changepw at EXAMPLE.COM Nov 08 14:48:23 fileserver2.example.com krb5kdc[1246](info): AS_REQ (7 etypes {18 17 16 23 1 3 2}) 192.168.1.20: NEEDED_PREAUTH: guser at EXAMPLE.COM for kadmin/changepw at EXAMPLE.COM, Additional pre-authentication required Nov 08 14:48:23 fileserver2.example.com krb5kdc[1246](info): AS_REQ (7 etypes {18 17 16 23 1 3 2}) 192.168.1.20: ISSUE: authtime 1289245703, etypes {rep=18 tkt=18 ses=18}, guser at EXAMPLE.COM for kadmin/changepw at EXAMPLE.COM This appears to work fine when using kinit to login for the first time. Shouldn't it work using SSH too? This will be a problem for our remote users, since they have to connect remotely, using SSH. Thanks, Dan Scott From rcritten at redhat.com Mon Nov 8 21:02:07 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 08 Nov 2010 16:02:07 -0500 Subject: [Freeipa-users] Error changing expired user password using SSH In-Reply-To: References: Message-ID: <4CD8654F.9080308@redhat.com> Dan Scott wrote: > Hi, > > I'm having problems with users accessing their accounts for the first > time using SSH. I create their account in FreeIPA and set a (expired) > password. Then I have them ssh into one of our computers to setup > their password. The connection displays the following: > > djscott at pc35:~$ ssh guser at pc20 > guser at pc20's password: > Warning: Your password will expire in less than one hour. > Warning: password has expired. > WARNING: Your password has expired. > You must change your password now and login again! > Changing password for user guser. > Kerberos 5 Password: > Warning: Your password will expire in less than one hour. > New password: > Retype new password: > passwd: Authentication token manipulation error > Connection to pc20 closed. > > And the password change fails. Here is the relevant section from the > Kerberos logfile. There is no entry in the LDAP log in dirsrv. > > Nov 08 14:48:21 fileserver2.example.com krb5kdc[1246](info): AS_REQ (7 > etypes {18 17 16 23 1 3 2}) 192.168.1.20: CLIENT KEY EXPIRED: > guser at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM, Password has > expired > Nov 08 14:48:21 fileserver2.example.com krb5kdc[1246](info): AS_REQ (7 > etypes {18 17 16 23 1 3 2}) 192.168.1.20: NEEDED_PREAUTH: > guser at EXAMPLE.COM for kadmin/changepw at EXAMPLE.COM, Additional > pre-authentication required > Nov 08 14:48:22 fileserver2.example.com krb5kdc[1246](info): AS_REQ (7 > etypes {18 17 16 23 1 3 2}) 192.168.1.20: ISSUE: authtime 1289245702, > etypes {rep=18 tkt=18 ses=18}, guser at EXAMPLE.COM for > kadmin/changepw at EXAMPLE.COM > Nov 08 14:48:23 fileserver2.example.com krb5kdc[1246](info): AS_REQ (7 > etypes {18 17 16 23 1 3 2}) 192.168.1.20: NEEDED_PREAUTH: > guser at EXAMPLE.COM for kadmin/changepw at EXAMPLE.COM, Additional > pre-authentication required > Nov 08 14:48:23 fileserver2.example.com krb5kdc[1246](info): AS_REQ (7 > etypes {18 17 16 23 1 3 2}) 192.168.1.20: ISSUE: authtime 1289245703, > etypes {rep=18 tkt=18 ses=18}, guser at EXAMPLE.COM for > kadmin/changepw at EXAMPLE.COM > > This appears to work fine when using kinit to login for the first > time. Shouldn't it work using SSH too? This will be a problem for our > remote users, since they have to connect remotely, using SSH. > > Thanks, > > Dan Scott You need to enable Challenge-Response in sshd. See: http://freeipa.org/page/Administrators_Guide#Using_Password_Authentication rob From rmeggins at redhat.com Mon Nov 8 21:06:19 2010 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 08 Nov 2010 14:06:19 -0700 Subject: [Freeipa-users] periodic failures on replicas ... In-Reply-To: <4CD8505D.9040906@mcnc.org> References: <4CD8505D.9040906@mcnc.org> Message-ID: <4CD8664B.6000206@redhat.com> Kambiz Aghaiepour wrote: > I'm seeing our IPA replicas periodically failing with errors of: > > [08/Nov/2010:08:12:02 -0500] - Not listening for new connections - too > many fds open > [08/Nov/2010:08:12:02 -0500] - Listening for new connections again > [08/Nov/2010:08:12:02 -0500] - Not listening for new connections - too > many fds open > [08/Nov/2010:08:12:02 -0500] - Listening for new connections again > > It's not clear to me what's triggering this condition. You have too many connections to the directory server and it is running out of file descriptors. You'll have to increase the number of file descriptors the directory server can use, or figure out if there are "rogue" clients opening too many connections but not closing them properly. You can use logconv.pl to analyze your access logs. See also http://directory.fedoraproject.org/wiki/Performance_Tuning#Linux and man sysctl - the parameter fs.file-max > When it happens, > we're restarting services on the replica (ipactl restart), and things go > back to normal for several days, until the next failure. I notice the > following during "normal" running of services : > > NSMMReplicationPlugin - repl_set_mtn_referrals: could not set referrals > for replica dc=example,dc=org: 1 > I think this is benign (but annoying) > (on both the consumers and provider). Is this an error I should worry > about ? > > Kambiz > From rcritten at redhat.com Mon Nov 8 21:52:13 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 08 Nov 2010 16:52:13 -0500 Subject: [Freeipa-users] certmonger selinux issue and freeipa dns database error problem In-Reply-To: References: Message-ID: <4CD8710D.5070608@redhat.com> Uzor Ide wrote: > > We have a network that relies on kerberos, 389-ds, bind and nfs4. I am > currently testing out the freeipa version 2 to see if we can use it to > consolidate the various configuration into one interface. For the most > part it works great apart from the obvious area where it has not been > completed. However there are somethings that I have noticed. Hey, sorry we didn't forget about you. Ticket https://fedorahosted.org/freeipa/ticket/409 was opened for your DNS problem. Do you get this query error frequently? Do you know what triggers it? I haven't been able to reproduce it myself yet. I wonder if this happens when logs roll. For the certmonger problem this looks like a new one to me, I'll file a bug. regards rob > 1.) The DNS logging always logs database error every time it access the > ldap. even though the query returns okay and the dns reply is fine. > > here is an excerpt of the log named.run > > 24-Oct-2010 10:32:33.025 edns-disabled: info: success resolving > 'www.mailscanner.tv/A ' (in 'mailscanner.tv > '?) after reducing the advertised EDNS UDP packet > size to 512 octets > 24-Oct-2010 10:34:41.137 database: error: querying 'idnsName=wpad, > idnsname=uzdomain.ca ,cn=dns,dc=uzdomain,dc=ca' with > '(objectClass=idnsRecord)' > 24-Oct-2010 10:34:41.140 database: error: querying 'idnsname=uzdomain.ca > ,cn=dns,dc=uzdomain,dc=ca' with > '(objectClass=idnsRecord)' > 24-Oct-2010 10:34:41.143 database: error: entry count: 1 > 24-Oct-2010 10:34:41.146 database: error: querying 'idnsName=wpad, > idnsname=uzdomain.ca ,cn=dns,dc=uzdomain,dc=ca' with > '(objectClass=idnsRecord)' > 24-Oct-2010 10:39:43.581 database: error: querying 'idnsName=wpad, > idnsname=uzdomain.ca ,cn=dns,dc=uzdomain,dc=ca' with > '(objectClass=idnsRecord)' > 24-Oct-2010 10:39:43.583 database: error: querying 'idnsname=uzdomain.ca > ,cn=dns,dc=uzdomain,dc=ca' with > '(objectClass=idnsRecord)' > 24-Oct-2010 10:39:43.586 database: error: entry count: 1 > 24-Oct-2010 10:39:43.589 database: error: querying 'idnsName=wpad, > idnsname=uzdomain.ca ,cn=dns,dc=uzdomain,dc=ca' with > '(objectClass=idnsRecord)' > > here is our logging configuration > > // ******************* > // Logging definitions > // ******************* > > // Logging > logging { > channel "named_log" { > file "data/log/named.run" versions 5 size 4m; > severity dynamic; > print-category yes; > print-severity yes; > print-time yes; > }; > > channel "security_log" { > file "data/log/security.log" versions 5 size 10m; > severity dynamic; > print-category yes; > print-severity yes; > print-time yes; > }; > > channel "query_log" { > file "data/log/query.log" versions 5 size 50m; > #severity dynamic; > severity debug; > print-category yes; > print-severity yes; > print-time yes; > }; > > channel "transfer_log" { > file "data/log/transfer.log" versions 5 size 10m; > severity dynamic; > print-category yes; > print-severity yes; > }; > > category "default" { > "named_log"; > "default_syslog"; > "default_debug"; > }; > > category "general" { > "named_log"; > }; > > category "queries" { > "query_log"; > }; > > category "lame-servers" { > null; > }; > > category "security" { > "security_log"; > }; > > category "config" { > "named_log"; > }; > > category "resolver" { > "query_log"; > }; > > category "xfer-in" { > "transfer_log"; > }; > > category "xfer-out" { > "transfer_log"; > }; > > category "notify" { > "transfer_log"; > }; > > category "client" { > "query_log"; > }; > > category "network" { > "named_log"; > }; > > category "update" { > "transfer_log"; > }; > > category "dnssec" { > "security_log"; > }; > > category "dispatch" { > "security_log"; > }; > }; > > This error message keeps triggering our monitoring systems. > > 2.) I currently have only one ipa-client; and certmonger keeps getting > seliux AVC denials > > Oct 24 10:57:24 ulasi setroubleshoot: SELinux is preventing > /usr/sbin/certmonger "execute" access on > /usr/libexec/certmonger/ipa-submit. For complete SELinux messages. run > sealert -l 8db766a3-6100-4be5-aec6-2a3a713290e2 > Oct 24 10:57:56 ulasi setroubleshoot: SELinux is preventing > /usr/sbin/certmonger "execute" access on > /usr/libexec/certmonger/ipa-submit. For complete SELinux messages. run > sealert -l 8db766a3-6100-4be5-aec6-2a3a713290e2 > Oct 24 10:58:26 ulasi setroubleshoot: SELinux is preventing > /usr/sbin/certmonger "execute" access on > /usr/libexec/certmonger/ipa-submit. For complete SELinux messages. run > sealert -l 8db766a3-6100-4be5-aec6-2a3a713290e2 > Oct 24 10:58:57 ulasi setroubleshoot: SELinux is preventing > /usr/sbin/certmonger "execute" access on > /usr/libexec/certmonger/ipa-submit. For complete SELinux messages. run > sealert -l 8db766a3-6100-4be5-aec6-2a3a713290e2 > > > Summary: > > SELinux is preventing /usr/sbin/certmonger "execute" access on > /usr/libexec/certmonger/ipa-submit. > > Detailed Description: > > SELinux denied access requested by certmonger. It is not expected that this > access is required by certmonger and this access may signal an intrusion > attempt. It is also possible that the specific version or configuration > of the > application is causing it to require additional access. > > Allowing Access: > > You can generate a local policy module to allow this access - see FAQ > (http://docs.fedoraproject.org/selinux-faq-fc5/#id2961385) Please file a bug > report. > > Additional Information: > > Source Context system_u:system_r:certmonger_t:s0 > Target Context system_u:object_r:bin_t:s0 > Target Objects /usr/libexec/certmonger/ipa-submit [ file ] > Source certmonger > Source Path /usr/sbin/certmonger > Port > Host ulasi.uzdomain.ca > Source RPM Packages certmonger-0.32-0.2010101515git5920eca.fc13 > Target RPM Packages certmonger-0.32-0.2010101515git5920eca.fc13 > Policy RPM selinux-policy-3.7.19-65.fc13 > Selinux Enabled True > Policy Type targeted > Enforcing Mode Enforcing > Plugin Name catchall > Host Name ulasi.uzdomain.ca > Platform Linux ulasi.uzdomain.ca > 2.6.34.7-61.fc13.i686.PAE > #1 SMP Tue Oct 19 04:24:06 UTC 2010 i686 i686 > Alert Count 1646 > First Seen Sat Oct 23 15:48:48 2010 > Last Seen Sun Oct 24 10:59:52 2010 > Local ID 8db766a3-6100-4be5-aec6-2a3a713290e2 > Line Numbers > > Raw Audit Messages > > node=ulasi.uzdomain.ca type=AVC > msg=audit(1287932392.282:21690): avc: denied { execute } for pid=3472 > comm="certmonger" name="ipa-submit" dev=dm-0 ino=790251 > scontext=system_u:system_r:certmonger_t:s0 > tcontext=system_u:object_r:bin_t:s0 tclass=file > > node=ulasi.uzdomain.ca type=SYSCALL > msg=audit(1287932392.282:21690): arch=40000003 syscall=11 success=no > exit=-13 a0=9f99490 a1=9f99450 a2=9f98e60 a3=9f99450 items=0 ppid=1555 > pid=3472 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 > fsgid=0 tty=(none) ses=4294967295 comm="certmonger" > exe="/usr/sbin/certmonger" subj=system_u:system_r:certmonger_t:s0 key=(null) > > I was using certmonger-0.30-1.fc13.i686 from source [ freeipa-devel ] > because of the problem I updated to the nightly build > certmonger-0.32-0.2010101515git5920eca.fc13 but the problem continues. > > These are the selinux rpms > selinux-policy-targeted-3.7.19-65.fc13.noarch > selinux-policy-3.7.19-65.fc13.noarch > libselinux-python-2.0.94-2.fc13.i686 > libselinux-utils-2.0.94-2.fc13.i686 > > Thanks > > Ide > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From rcritten at redhat.com Tue Nov 9 14:46:50 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 09 Nov 2010 09:46:50 -0500 Subject: [Freeipa-users] certmonger selinux issue and freeipa dns database error problem In-Reply-To: <4CD8710D.5070608@redhat.com> References: <4CD8710D.5070608@redhat.com> Message-ID: <4CD95EDA.6030107@redhat.com> Rob Crittenden wrote: > Uzor Ide wrote: >> >> We have a network that relies on kerberos, 389-ds, bind and nfs4. I am >> currently testing out the freeipa version 2 to see if we can use it to >> consolidate the various configuration into one interface. For the most >> part it works great apart from the obvious area where it has not been >> completed. However there are somethings that I have noticed. > > Hey, sorry we didn't forget about you. Ticket > https://fedorahosted.org/freeipa/ticket/409 was opened for your DNS > problem. > > Do you get this query error frequently? Do you know what triggers it? I > haven't been able to reproduce it myself yet. I wonder if this happens > when logs roll. > > For the certmonger problem this looks like a new one to me, I'll file a > bug. > > regards > > rob > >> 1.) The DNS logging always logs database error every time it access the >> ldap. even though the query returns okay and the dns reply is fine. >> >> here is an excerpt of the log named.run >> >> 24-Oct-2010 10:32:33.025 edns-disabled: info: success resolving >> 'www.mailscanner.tv/A ' (in 'mailscanner.tv >> '?) after reducing the advertised EDNS UDP packet >> size to 512 octets >> 24-Oct-2010 10:34:41.137 database: error: querying 'idnsName=wpad, >> idnsname=uzdomain.ca ,cn=dns,dc=uzdomain,dc=ca' with >> '(objectClass=idnsRecord)' >> 24-Oct-2010 10:34:41.140 database: error: querying 'idnsname=uzdomain.ca >> ,cn=dns,dc=uzdomain,dc=ca' with >> '(objectClass=idnsRecord)' >> 24-Oct-2010 10:34:41.143 database: error: entry count: 1 >> 24-Oct-2010 10:34:41.146 database: error: querying 'idnsName=wpad, >> idnsname=uzdomain.ca ,cn=dns,dc=uzdomain,dc=ca' with >> '(objectClass=idnsRecord)' >> 24-Oct-2010 10:39:43.581 database: error: querying 'idnsName=wpad, >> idnsname=uzdomain.ca ,cn=dns,dc=uzdomain,dc=ca' with >> '(objectClass=idnsRecord)' >> 24-Oct-2010 10:39:43.583 database: error: querying 'idnsname=uzdomain.ca >> ,cn=dns,dc=uzdomain,dc=ca' with >> '(objectClass=idnsRecord)' >> 24-Oct-2010 10:39:43.586 database: error: entry count: 1 >> 24-Oct-2010 10:39:43.589 database: error: querying 'idnsName=wpad, >> idnsname=uzdomain.ca ,cn=dns,dc=uzdomain,dc=ca' with >> '(objectClass=idnsRecord)' >> >> here is our logging configuration >> >> // ******************* >> // Logging definitions >> // ******************* >> >> // Logging >> logging { >> channel "named_log" { >> file "data/log/named.run" versions 5 size 4m; >> severity dynamic; >> print-category yes; >> print-severity yes; >> print-time yes; >> }; >> >> channel "security_log" { >> file "data/log/security.log" versions 5 size 10m; >> severity dynamic; >> print-category yes; >> print-severity yes; >> print-time yes; >> }; >> >> channel "query_log" { >> file "data/log/query.log" versions 5 size 50m; >> #severity dynamic; >> severity debug; >> print-category yes; >> print-severity yes; >> print-time yes; >> }; >> >> channel "transfer_log" { >> file "data/log/transfer.log" versions 5 size 10m; >> severity dynamic; >> print-category yes; >> print-severity yes; >> }; >> >> category "default" { >> "named_log"; >> "default_syslog"; >> "default_debug"; >> }; >> >> category "general" { >> "named_log"; >> }; >> >> category "queries" { >> "query_log"; >> }; >> >> category "lame-servers" { >> null; >> }; >> >> category "security" { >> "security_log"; >> }; >> >> category "config" { >> "named_log"; >> }; >> >> category "resolver" { >> "query_log"; >> }; >> >> category "xfer-in" { >> "transfer_log"; >> }; >> >> category "xfer-out" { >> "transfer_log"; >> }; >> >> category "notify" { >> "transfer_log"; >> }; >> >> category "client" { >> "query_log"; >> }; >> >> category "network" { >> "named_log"; >> }; >> >> category "update" { >> "transfer_log"; >> }; >> >> category "dnssec" { >> "security_log"; >> }; >> >> category "dispatch" { >> "security_log"; >> }; >> }; >> >> This error message keeps triggering our monitoring systems. >> >> 2.) I currently have only one ipa-client; and certmonger keeps getting >> seliux AVC denials >> >> Oct 24 10:57:24 ulasi setroubleshoot: SELinux is preventing >> /usr/sbin/certmonger "execute" access on >> /usr/libexec/certmonger/ipa-submit. For complete SELinux messages. run >> sealert -l 8db766a3-6100-4be5-aec6-2a3a713290e2 >> Oct 24 10:57:56 ulasi setroubleshoot: SELinux is preventing >> /usr/sbin/certmonger "execute" access on >> /usr/libexec/certmonger/ipa-submit. For complete SELinux messages. run >> sealert -l 8db766a3-6100-4be5-aec6-2a3a713290e2 >> Oct 24 10:58:26 ulasi setroubleshoot: SELinux is preventing >> /usr/sbin/certmonger "execute" access on >> /usr/libexec/certmonger/ipa-submit. For complete SELinux messages. run >> sealert -l 8db766a3-6100-4be5-aec6-2a3a713290e2 >> Oct 24 10:58:57 ulasi setroubleshoot: SELinux is preventing >> /usr/sbin/certmonger "execute" access on >> /usr/libexec/certmonger/ipa-submit. For complete SELinux messages. run >> sealert -l 8db766a3-6100-4be5-aec6-2a3a713290e2 >> >> >> Summary: >> >> SELinux is preventing /usr/sbin/certmonger "execute" access on >> /usr/libexec/certmonger/ipa-submit. >> >> Detailed Description: >> >> SELinux denied access requested by certmonger. It is not expected that >> this >> access is required by certmonger and this access may signal an intrusion >> attempt. It is also possible that the specific version or configuration >> of the >> application is causing it to require additional access. >> >> Allowing Access: >> >> You can generate a local policy module to allow this access - see FAQ >> (http://docs.fedoraproject.org/selinux-faq-fc5/#id2961385) Please file >> a bug >> report. >> >> Additional Information: >> >> Source Context system_u:system_r:certmonger_t:s0 >> Target Context system_u:object_r:bin_t:s0 >> Target Objects /usr/libexec/certmonger/ipa-submit [ file ] >> Source certmonger >> Source Path /usr/sbin/certmonger >> Port >> Host ulasi.uzdomain.ca >> Source RPM Packages certmonger-0.32-0.2010101515git5920eca.fc13 >> Target RPM Packages certmonger-0.32-0.2010101515git5920eca.fc13 >> Policy RPM selinux-policy-3.7.19-65.fc13 >> Selinux Enabled True >> Policy Type targeted >> Enforcing Mode Enforcing >> Plugin Name catchall >> Host Name ulasi.uzdomain.ca >> Platform Linux ulasi.uzdomain.ca >> 2.6.34.7-61.fc13.i686.PAE >> #1 SMP Tue Oct 19 04:24:06 UTC 2010 i686 i686 >> Alert Count 1646 >> First Seen Sat Oct 23 15:48:48 2010 >> Last Seen Sun Oct 24 10:59:52 2010 >> Local ID 8db766a3-6100-4be5-aec6-2a3a713290e2 >> Line Numbers >> >> Raw Audit Messages >> >> node=ulasi.uzdomain.ca type=AVC >> msg=audit(1287932392.282:21690): avc: denied { execute } for pid=3472 >> comm="certmonger" name="ipa-submit" dev=dm-0 ino=790251 >> scontext=system_u:system_r:certmonger_t:s0 >> tcontext=system_u:object_r:bin_t:s0 tclass=file >> >> node=ulasi.uzdomain.ca type=SYSCALL >> msg=audit(1287932392.282:21690): arch=40000003 syscall=11 success=no >> exit=-13 a0=9f99490 a1=9f99450 a2=9f98e60 a3=9f99450 items=0 ppid=1555 >> pid=3472 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 >> fsgid=0 tty=(none) ses=4294967295 comm="certmonger" >> exe="/usr/sbin/certmonger" subj=system_u:system_r:certmonger_t:s0 >> key=(null) >> >> I was using certmonger-0.30-1.fc13.i686 from source [ freeipa-devel ] >> because of the problem I updated to the nightly build >> certmonger-0.32-0.2010101515git5920eca.fc13 but the problem continues. >> >> These are the selinux rpms >> selinux-policy-targeted-3.7.19-65.fc13.noarch >> selinux-policy-3.7.19-65.fc13.noarch >> libselinux-python-2.0.94-2.fc13.i686 >> libselinux-utils-2.0.94-2.fc13.i686 Uzor, the SELinux guys have updated the bug asking this: Can you execute: # semanage permissive -a certmonger_t and re-test it. After that execute # ausearch -m avc -ts recent I just want to see if you get another AVC messages. Thanks. rob From ide4you at gmail.com Tue Nov 9 17:32:11 2010 From: ide4you at gmail.com (Uzor Ide) Date: Tue, 9 Nov 2010 12:32:11 -0500 Subject: [Freeipa-users] certmonger selinux issue and freeipa dns database error problem In-Reply-To: <4CD95EDA.6030107@redhat.com> References: <4CD8710D.5070608@redhat.com> <4CD95EDA.6030107@redhat.com> Message-ID: I no longer get that AVC messages after going through the steps I described on Bugzilla. I ran your command and it came back with On the issue of database error in bind logs. It is always there, whenever bind does a ldap lookup for any dns entry. However doesn't affect or stop it from returning the correct query results. It just that the prefix database error on each ldap lookup causes our monitoring system to go crazy. I have updated from version 1.9.0-pre4 to the nightly builds but it did not make any difference. If anything I now lost the web interface. The web interface is not a problem since I don't use it anyway. Thanks Ide On Tue, Nov 9, 2010 at 9:46 AM, Rob Crittenden wrote: > Rob Crittenden wrote: > >> Uzor Ide wrote: >> >>> >>> We have a network that relies on kerberos, 389-ds, bind and nfs4. I am >>> currently testing out the freeipa version 2 to see if we can use it to >>> consolidate the various configuration into one interface. For the most >>> part it works great apart from the obvious area where it has not been >>> completed. However there are somethings that I have noticed. >>> >> >> Hey, sorry we didn't forget about you. Ticket >> https://fedorahosted.org/freeipa/ticket/409 was opened for your DNS >> problem. >> >> Do you get this query error frequently? Do you know what triggers it? I >> haven't been able to reproduce it myself yet. I wonder if this happens >> when logs roll. >> >> For the certmonger problem this looks like a new one to me, I'll file a >> bug. >> >> regards >> >> rob >> >> 1.) The DNS logging always logs database error every time it access the >>> ldap. even though the query returns okay and the dns reply is fine. >>> >>> here is an excerpt of the log named.run >>> >>> 24-Oct-2010 10:32:33.025 edns-disabled: info: success resolving >>> 'www.mailscanner.tv/A ' (in 'mailscanner.tv >>> '?) after reducing the advertised EDNS UDP packet >>> size to 512 octets >>> 24-Oct-2010 10:34:41.137 database: error: querying 'idnsName=wpad, >>> idnsname=uzdomain.ca ,cn=dns,dc=uzdomain,dc=ca' with >>> '(objectClass=idnsRecord)' >>> 24-Oct-2010 10:34:41.140 database: error: querying 'idnsname=uzdomain.ca >>> ,cn=dns,dc=uzdomain,dc=ca' with >>> '(objectClass=idnsRecord)' >>> 24-Oct-2010 10:34:41.143 database: error: entry count: 1 >>> 24-Oct-2010 10:34:41.146 database: error: querying 'idnsName=wpad, >>> idnsname=uzdomain.ca ,cn=dns,dc=uzdomain,dc=ca' with >>> '(objectClass=idnsRecord)' >>> 24-Oct-2010 10:39:43.581 database: error: querying 'idnsName=wpad, >>> idnsname=uzdomain.ca ,cn=dns,dc=uzdomain,dc=ca' with >>> '(objectClass=idnsRecord)' >>> 24-Oct-2010 10:39:43.583 database: error: querying 'idnsname=uzdomain.ca >>> ,cn=dns,dc=uzdomain,dc=ca' with >>> '(objectClass=idnsRecord)' >>> 24-Oct-2010 10:39:43.586 database: error: entry count: 1 >>> 24-Oct-2010 10:39:43.589 database: error: querying 'idnsName=wpad, >>> idnsname=uzdomain.ca ,cn=dns,dc=uzdomain,dc=ca' with >>> '(objectClass=idnsRecord)' >>> >>> here is our logging configuration >>> >>> // ******************* >>> // Logging definitions >>> // ******************* >>> >>> // Logging >>> logging { >>> channel "named_log" { >>> file "data/log/named.run" versions 5 size 4m; >>> severity dynamic; >>> print-category yes; >>> print-severity yes; >>> print-time yes; >>> }; >>> >>> channel "security_log" { >>> file "data/log/security.log" versions 5 size 10m; >>> severity dynamic; >>> print-category yes; >>> print-severity yes; >>> print-time yes; >>> }; >>> >>> channel "query_log" { >>> file "data/log/query.log" versions 5 size 50m; >>> #severity dynamic; >>> severity debug; >>> print-category yes; >>> print-severity yes; >>> print-time yes; >>> }; >>> >>> channel "transfer_log" { >>> file "data/log/transfer.log" versions 5 size 10m; >>> severity dynamic; >>> print-category yes; >>> print-severity yes; >>> }; >>> >>> category "default" { >>> "named_log"; >>> "default_syslog"; >>> "default_debug"; >>> }; >>> >>> category "general" { >>> "named_log"; >>> }; >>> >>> category "queries" { >>> "query_log"; >>> }; >>> >>> category "lame-servers" { >>> null; >>> }; >>> >>> category "security" { >>> "security_log"; >>> }; >>> >>> category "config" { >>> "named_log"; >>> }; >>> >>> category "resolver" { >>> "query_log"; >>> }; >>> >>> category "xfer-in" { >>> "transfer_log"; >>> }; >>> >>> category "xfer-out" { >>> "transfer_log"; >>> }; >>> >>> category "notify" { >>> "transfer_log"; >>> }; >>> >>> category "client" { >>> "query_log"; >>> }; >>> >>> category "network" { >>> "named_log"; >>> }; >>> >>> category "update" { >>> "transfer_log"; >>> }; >>> >>> category "dnssec" { >>> "security_log"; >>> }; >>> >>> category "dispatch" { >>> "security_log"; >>> }; >>> }; >>> >>> This error message keeps triggering our monitoring systems. >>> >>> 2.) I currently have only one ipa-client; and certmonger keeps getting >>> seliux AVC denials >>> >>> Oct 24 10:57:24 ulasi setroubleshoot: SELinux is preventing >>> /usr/sbin/certmonger "execute" access on >>> /usr/libexec/certmonger/ipa-submit. For complete SELinux messages. run >>> sealert -l 8db766a3-6100-4be5-aec6-2a3a713290e2 >>> Oct 24 10:57:56 ulasi setroubleshoot: SELinux is preventing >>> /usr/sbin/certmonger "execute" access on >>> /usr/libexec/certmonger/ipa-submit. For complete SELinux messages. run >>> sealert -l 8db766a3-6100-4be5-aec6-2a3a713290e2 >>> Oct 24 10:58:26 ulasi setroubleshoot: SELinux is preventing >>> /usr/sbin/certmonger "execute" access on >>> /usr/libexec/certmonger/ipa-submit. For complete SELinux messages. run >>> sealert -l 8db766a3-6100-4be5-aec6-2a3a713290e2 >>> Oct 24 10:58:57 ulasi setroubleshoot: SELinux is preventing >>> /usr/sbin/certmonger "execute" access on >>> /usr/libexec/certmonger/ipa-submit. For complete SELinux messages. run >>> sealert -l 8db766a3-6100-4be5-aec6-2a3a713290e2 >>> >>> >>> Summary: >>> >>> SELinux is preventing /usr/sbin/certmonger "execute" access on >>> /usr/libexec/certmonger/ipa-submit. >>> >>> Detailed Description: >>> >>> SELinux denied access requested by certmonger. It is not expected that >>> this >>> access is required by certmonger and this access may signal an intrusion >>> attempt. It is also possible that the specific version or configuration >>> of the >>> application is causing it to require additional access. >>> >>> Allowing Access: >>> >>> You can generate a local policy module to allow this access - see FAQ >>> (http://docs.fedoraproject.org/selinux-faq-fc5/#id2961385) Please file >>> a bug >>> report. >>> >>> Additional Information: >>> >>> Source Context system_u:system_r:certmonger_t:s0 >>> Target Context system_u:object_r:bin_t:s0 >>> Target Objects /usr/libexec/certmonger/ipa-submit [ file ] >>> Source certmonger >>> Source Path /usr/sbin/certmonger >>> Port >>> Host ulasi.uzdomain.ca >>> Source RPM Packages certmonger-0.32-0.2010101515git5920eca.fc13 >>> Target RPM Packages certmonger-0.32-0.2010101515git5920eca.fc13 >>> Policy RPM selinux-policy-3.7.19-65.fc13 >>> Selinux Enabled True >>> Policy Type targeted >>> Enforcing Mode Enforcing >>> Plugin Name catchall >>> Host Name ulasi.uzdomain.ca >>> Platform Linux ulasi.uzdomain.ca >>> 2.6.34.7-61.fc13.i686.PAE >>> #1 SMP Tue Oct 19 04:24:06 UTC 2010 i686 i686 >>> Alert Count 1646 >>> First Seen Sat Oct 23 15:48:48 2010 >>> Last Seen Sun Oct 24 10:59:52 2010 >>> Local ID 8db766a3-6100-4be5-aec6-2a3a713290e2 >>> Line Numbers >>> >>> Raw Audit Messages >>> >>> node=ulasi.uzdomain.ca type=AVC >>> msg=audit(1287932392.282:21690): avc: denied { execute } for pid=3472 >>> comm="certmonger" name="ipa-submit" dev=dm-0 ino=790251 >>> scontext=system_u:system_r:certmonger_t:s0 >>> tcontext=system_u:object_r:bin_t:s0 tclass=file >>> >>> node=ulasi.uzdomain.ca type=SYSCALL >>> msg=audit(1287932392.282:21690): arch=40000003 syscall=11 success=no >>> exit=-13 a0=9f99490 a1=9f99450 a2=9f98e60 a3=9f99450 items=0 ppid=1555 >>> pid=3472 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 >>> fsgid=0 tty=(none) ses=4294967295 comm="certmonger" >>> exe="/usr/sbin/certmonger" subj=system_u:system_r:certmonger_t:s0 >>> key=(null) >>> >>> I was using certmonger-0.30-1.fc13.i686 from source [ freeipa-devel ] >>> because of the problem I updated to the nightly build >>> certmonger-0.32-0.2010101515git5920eca.fc13 but the problem continues. >>> >>> These are the selinux rpms >>> selinux-policy-targeted-3.7.19-65.fc13.noarch >>> selinux-policy-3.7.19-65.fc13.noarch >>> libselinux-python-2.0.94-2.fc13.i686 >>> libselinux-utils-2.0.94-2.fc13.i686 >>> >> > Uzor, the SELinux guys have updated the bug asking this: > > Can you execute: > > # semanage permissive -a certmonger_t > > and re-test it. After that execute > > # ausearch -m avc -ts recent > > > I just want to see if you get another AVC messages. Thanks. > > rob > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sailer at sailer.dynip.lugs.ch Thu Nov 11 12:44:55 2010 From: sailer at sailer.dynip.lugs.ch (Thomas Sailer) Date: Thu, 11 Nov 2010 13:44:55 +0100 Subject: [Freeipa-users] Secure nfs4 and Fedora 14 Message-ID: <1289479495.17469.22.camel@xbox360.hq.axsem.com> Since I upgraded about two days ago from a fully up-to-date and working Fedora13 system to Fedora14, I am unable to mount the krb5p nfs4 shares of the freeipa server (which is itself running a fully up-to-date Fedora12). rpc.gssd on the client reports the following: beginning poll dir_notify_handler: sig 37 si 0x7fff99e83030 data 0x7fff99e82f00 dir_notify_handler: sig 37 si 0x7fff99e7f930 data 0x7fff99e7f800 dir_notify_handler: sig 37 si 0x7fff99e82ef0 data 0x7fff99e82dc0 handling gssd upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt38) handle_gssd_upcall: 'mech=krb5 uid=0 enctypes=18,17,16,23,3,1,2 ' handling krb5 upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt38) process_krb5_upcall: service is '' Full hostname for 'server.xxxx.xxx' is 'server.xxxx.xxx' Full hostname for 'clnt.xxxx.xxx' is 'clnt.xxxx.xxx' Key table entry not found while getting keytab entry for 'root/clnt.xxxx.xxx at XXXX.XXX' Success getting keytab entry for 'nfs/clnt.xxxx.xxx at XXXX.XXX' Successfully obtained machine credentials for principal 'nfs/clnt.xxxx.xxx at XXXX.XXX' stored in ccache 'FILE:/tmp/krb5cc_machine_XXXX.XXX' INFO: Credentials in CC 'FILE:/tmp/krb5cc_machine_XXXX.XXX' are good until 1289651734 using FILE:/tmp/krb5cc_machine_XXXX.XXX as credentials cache for machine creds using environment variable to select krb5 ccache FILE:/tmp/krb5cc_machine_XXXX.XXX creating context using fsuid 0 (save_uid 0) creating tcp client for server server.xxxx.xxx DEBUG: port already set to 2049 creating context with server nfs at server.xxxx.xxx WARNING: Failed to create krb5 context for user with uid 0 for server server.xxxx.xxx WARNING: Failed to create machine krb5 context with credentials cache FILE:/tmp/krb5cc_machine_XXXX.XXX for server server.xxxx.xxx WARNING: Machine cache is prematurely expired or corrupted trying to recreate cache for server server.xxxx.xxx Full hostname for 'server.xxxx.xxx' is 'server.xxxx.xxx' Full hostname for 'clnt.xxxx.xxx' is 'clnt.xxxx.xxx' Key table entry not found while getting keytab entry for 'root/clnt.xxxx.xxx at XXXX.XXX' Success getting keytab entry for 'nfs/clnt.xxxx.xxx at XXXX.XXX' INFO: Credentials in CC 'FILE:/tmp/krb5cc_machine_XXXX.XXX' are good until 1289651734 INFO: Credentials in CC 'FILE:/tmp/krb5cc_machine_XXXX.XXX' are good until 1289651734 using FILE:/tmp/krb5cc_machine_XXXX.XXX as credentials cache for machine creds using environment variable to select krb5 ccache FILE:/tmp/krb5cc_machine_XXXX.XXX creating context using fsuid 0 (save_uid 0) creating tcp client for server server.xxxx.xxx DEBUG: port already set to 2049 creating context with server nfs at server.xxxx.xxx WARNING: Failed to create krb5 context for user with uid 0 for server server.xxxx.xxx WARNING: Failed to create machine krb5 context with credentials cache FILE:/tmp/krb5cc_machine_XXXX.XXX for server server.xxxx.xxx WARNING: Failed to create machine krb5 context with any credentials cache for server server.xxxx.xxx doing error downcall dir_notify_handler: sig 37 si 0x7fff99e83030 data 0x7fff99e82f00 dir_notify_handler: sig 37 si 0x7fff99e83030 data 0x7fff99e82f00 dir_notify_handler: sig 37 si 0x7fff99e82f30 data 0x7fff99e82e00 dir_notify_handler: sig 37 si 0x7fff99e7dfb0 data 0x7fff99e7de80 dir_notify_handler: sig 37 si 0x7fff99e7dfb0 data 0x7fff99e7de80 dir_notify_handler: sig 37 si 0x7fff99e7dfb0 data 0x7fff99e7de80 dir_notify_handler: sig 37 si 0x7fff99e7dfb0 data 0x7fff99e7de80 destroying client /var/lib/nfs/rpc_pipefs/nfs/clnt39 destroying client /var/lib/nfs/rpc_pipefs/nfs/clnt38 I need to downgrade the kernel and krb5* to the Fedora13 version to get nfs4 working again. Does anybody have an idea why it no longer works? What is the current party line with respect to nfs4 encryption types? The admin guide on the freeipa web page still requires des-cbc-crc. But MIT Kerberos seems to become increasingly hostile against des. And yes, I do have allow_weak_crypto = true in krb5.conf/libdefaults Thanks, Tom From ssorce at redhat.com Thu Nov 11 13:48:36 2010 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 11 Nov 2010 08:48:36 -0500 Subject: [Freeipa-users] Secure nfs4 and Fedora 14 In-Reply-To: <1289479495.17469.22.camel@xbox360.hq.axsem.com> References: <1289479495.17469.22.camel@xbox360.hq.axsem.com> Message-ID: <20101111084836.0c984a4b@willson.li.ssimo.org> On Thu, 11 Nov 2010 13:44:55 +0100 Thomas Sailer wrote: > Since I upgraded about two days ago from a fully up-to-date and > working Fedora13 system to Fedora14, I am unable to mount the krb5p > nfs4 shares of the freeipa server (which is itself running a fully > up-to-date Fedora12). > > rpc.gssd on the client reports the following: > > beginning poll > dir_notify_handler: sig 37 si 0x7fff99e83030 data 0x7fff99e82f00 > dir_notify_handler: sig 37 si 0x7fff99e7f930 data 0x7fff99e7f800 > dir_notify_handler: sig 37 si 0x7fff99e82ef0 data 0x7fff99e82dc0 > handling gssd upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt38) > handle_gssd_upcall: 'mech=krb5 uid=0 enctypes=18,17,16,23,3,1,2 ' > handling krb5 upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt38) > process_krb5_upcall: service is '' > Full hostname for 'server.xxxx.xxx' is 'server.xxxx.xxx' > Full hostname for 'clnt.xxxx.xxx' is 'clnt.xxxx.xxx' > Key table entry not found while getting keytab entry for > 'root/clnt.xxxx.xxx at XXXX.XXX' Success getting keytab entry for > 'nfs/clnt.xxxx.xxx at XXXX.XXX' Successfully obtained machine > credentials for principal 'nfs/clnt.xxxx.xxx at XXXX.XXX' stored in > ccache 'FILE:/tmp/krb5cc_machine_XXXX.XXX' INFO: Credentials in CC > 'FILE:/tmp/krb5cc_machine_XXXX.XXX' are good until 1289651734 using > FILE:/tmp/krb5cc_machine_XXXX.XXX as credentials cache for machine > creds using environment variable to select krb5 ccache > FILE:/tmp/krb5cc_machine_XXXX.XXX creating context using fsuid 0 > (save_uid 0) creating tcp client for server server.xxxx.xxx DEBUG: > port already set to 2049 creating context with server > nfs at server.xxxx.xxx WARNING: Failed to create krb5 context for user > with uid 0 for server server.xxxx.xxx WARNING: Failed to create > machine krb5 context with credentials cache > FILE:/tmp/krb5cc_machine_XXXX.XXX for server server.xxxx.xxx WARNING: > Machine cache is prematurely expired or corrupted trying to recreate > cache for server server.xxxx.xxx Full hostname for 'server.xxxx.xxx' > is 'server.xxxx.xxx' Full hostname for 'clnt.xxxx.xxx' is > 'clnt.xxxx.xxx' Key table entry not found while getting keytab entry > for 'root/clnt.xxxx.xxx at XXXX.XXX' Success getting keytab entry for > 'nfs/clnt.xxxx.xxx at XXXX.XXX' INFO: Credentials in CC > 'FILE:/tmp/krb5cc_machine_XXXX.XXX' are good until 1289651734 INFO: > Credentials in CC 'FILE:/tmp/krb5cc_machine_XXXX.XXX' are good until > 1289651734 using FILE:/tmp/krb5cc_machine_XXXX.XXX as credentials > cache for machine creds using environment variable to select krb5 > ccache FILE:/tmp/krb5cc_machine_XXXX.XXX creating context using fsuid > 0 (save_uid 0) creating tcp client for server server.xxxx.xxx DEBUG: > port already set to 2049 creating context with server > nfs at server.xxxx.xxx WARNING: Failed to create krb5 context for user > with uid 0 for server server.xxxx.xxx WARNING: Failed to create > machine krb5 context with credentials cache > FILE:/tmp/krb5cc_machine_XXXX.XXX for server server.xxxx.xxx WARNING: > Failed to create machine krb5 context with any credentials cache for > server server.xxxx.xxx doing error downcall dir_notify_handler: sig > 37 si 0x7fff99e83030 data 0x7fff99e82f00 dir_notify_handler: sig 37 > si 0x7fff99e83030 data 0x7fff99e82f00 dir_notify_handler: sig 37 si > 0x7fff99e82f30 data 0x7fff99e82e00 dir_notify_handler: sig 37 si > 0x7fff99e7dfb0 data 0x7fff99e7de80 dir_notify_handler: sig 37 si > 0x7fff99e7dfb0 data 0x7fff99e7de80 dir_notify_handler: sig 37 si > 0x7fff99e7dfb0 data 0x7fff99e7de80 dir_notify_handler: sig 37 si > 0x7fff99e7dfb0 data 0x7fff99e7de80 destroying > client /var/lib/nfs/rpc_pipefs/nfs/clnt39 destroying > client /var/lib/nfs/rpc_pipefs/nfs/clnt38 > > I need to downgrade the kernel and krb5* to the Fedora13 version to > get nfs4 working again. > > Does anybody have an idea why it no longer works? > > What is the current party line with respect to nfs4 encryption types? > The admin guide on the freeipa web page still requires des-cbc-crc. > But MIT Kerberos seems to become increasingly hostile against des. > And yes, I do have allow_weak_crypto = true in krb5.conf/libdefaults Starting with F14 you can use any crypto for NFS. However DES should still just work if you have a DES key. This looks like a kernel/rpc.gssd bug, I would file a ticket against those components. Simo. -- Simo Sorce * Red Hat, Inc * New York From sailer at sailer.dynip.lugs.ch Thu Nov 11 14:20:29 2010 From: sailer at sailer.dynip.lugs.ch (Thomas Sailer) Date: Thu, 11 Nov 2010 15:20:29 +0100 Subject: [Freeipa-users] Secure nfs4 and Fedora 14 In-Reply-To: <20101111084836.0c984a4b@willson.li.ssimo.org> References: <1289479495.17469.22.camel@xbox360.hq.axsem.com> <20101111084836.0c984a4b@willson.li.ssimo.org> Message-ID: <1289485229.31688.5.camel@xbox360.hq.axsem.com> On Thu, 2010-11-11 at 08:48 -0500, Simo Sorce wrote: > Starting with F14 you can use any crypto for NFS. However DES should > still just work if you have a DES key. > This looks like a kernel/rpc.gssd bug, I would file a ticket against > those components. Ok: https://bugzilla.redhat.com/show_bug.cgi?id=652275 https://bugzilla.redhat.com/show_bug.cgi?id=652273 Thanks, Tom From rcritten at redhat.com Thu Nov 11 17:52:04 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 11 Nov 2010 12:52:04 -0500 Subject: [Freeipa-users] Announcing FreeIPA v2 Server Alpha 5 Release Message-ID: <4CDC2D44.1010602@redhat.com> To all freeipa-interest, freeipa-users and freeipa-devel list members, The FreeIPA project team is pleased to announce the availability of the Alpha 5 release of freeIPA 2.0 server [1]. Binaries are available for F-12, F-13 and F-14. This alpha is a bug fix release over the previous alpha and includes a completely re-written UI. Please do not hesitate to share feedback, criticism or bugs with us on our mailing list: freeipa-users at redhat.com The changes in this release include: - Dropped our PKCS#10 parser to use the one provided by python-nss - Started enforcing that hosts must be resolvable before adding them (use --force if you really want to add them). - Provide a reason when adding members to a group fails. - Allow de-coupling of user private groups (group-detach). - Support for ipa tool failover. - Hosts are allowed to retrieve keytabs for their services. - More configurable logging, see http://freeipa.org/page/IPAv2_config_files - Add support for ldap:///self aci rules - Use global time and size limit values when searching. - Don't include passwords in log files. - Work on F-14 - Make ipactl a lot smarter and add a man page for it. - Have certmonger track the IPA service certificates. - Initial support for SUDO. You can create the objects but the client-side is not done yet. - The delete commands now take multiple arguments: ipa user-del user1 user2 user3 ... usern - Remove reliance on 'admin' as a special user. All access control now granted via groups. - Groups are now created as POSIX by default. - Add options to control NTLM hashes. By default LM hash is disabled. - Remove the correct password from the history. We were mistakenly removing the latest password from the history instead of the oldest. - Rename user-lock and user-unlock to user-enable user-disable. - The ipa command should return non-zero when something fails. - Add gettext support for the C utilities. - Add capability to import automount files. - Add basic support for user and group renames (more work is needed). For now use ipa user-mod --setattr uid=newuser olduser - Add flag to group-find to only search on private groups. - Set default python encoding to utf-8. This should resolve a number of i18n problems. - Show indirect members (of groups, hostgroups, netgroups, etc). - Remove group nesting from the HBAC service groups. - Implement nested netgroups. - Add basic support for kerberos lockout policy. You can control how many failed attempts are allowed before lockout. What is missing is a way to unlock a user. This depends on fixes from MIT Kerberos 1.9. - Correct handling of userCategory and hostCategory in netgroups. - Updated a lot of man pages. Known issues: - dogtag does not work out-of-the-box on Fedora 14. To fix it for for the time being run: # ln -s /usr/share/java/xalan-j2-serializer.jar /usr/share/tomcat5/common/lib/xalan-j2-serializer.jar rob [1] http://www.freeipa.org/page/Downloads