Re: [Freeipa-users] ipa and cronjob
On Wednesday, November 14, 2012 08:30:48 AM Simo Sorce wrote: > > > Just FYI, this is not strictly true, look at the -P, --password option > > > of ipa-getkeytab > > > > > > > > Thanks. I didn't notice that option since I'd been using this method > > since before I started using IPA. > > > > > > > > Is the password used to genterate a principle still usable after a keytab > > has been exported? I seem to remember from my pre-IPA days of using a > > plain old standalone MIT KDC that I couldn't use the password to > > authenticate after they keytab had been exported using kadmin. Again, I > > never really investigated it, but the password never seemed to work after > > the keytab was exported. > If you ask kadmin to randomize the password, then you are basically > changing the password at the time you export the keytab with a random > one, so your old password won't work anymore and you do not know the > new random one. > > But if you tell ipa-getkeytab to use a specific secret when generating > the keytab that is what is used to generate the new keys, so whether you > use pre-computed hashes in the keytab or manually regenerate them at > kinit time using a password it makes no difference. > > Of course if you then change your password or get a new keytab you will > change again keys so the repvious password/keytab won't work anymore. > > Simo. Thanks Simo and Petr for clarifying this. This is something that I'll definitely take a look at now having this information. -A -- Anthony - http://messinet.com - http://messinet.com/~amessina/gallery 8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E signature.asc Description: This is a digitally signed message part. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa and cronjob
On Wednesday, November 14, 2012 09:42:03 AM Petr Spacek wrote: > >> Just FYI, this is not strictly true, look at the -P, --password option > >> of ipa-getkeytab > > > > Thanks. I didn't notice that option since I'd been using this method > > since > > before I started using IPA. > > > > Is the password used to genterate a principle still usable after a keytab > > has been exported? I seem to remember from my pre-IPA days of using a > > plain old standalone MIT KDC that I couldn't use the password to > > authenticate after they keytab had been exported using kadmin. Again, I > > never really investigated it, but the password never seemed to work after > > the keytab was exported. > Kadmin from original MIT Kerberos has to flavors: kadmin and kadmin.local. > > Only "kadmin.local" (which works locally on KDC) can export keytab without > re-generating key (i.e. password). > > Network version - "kadmin" - have to re-generate key before each export. Petr, you are right. I never knew that distinction between kadmin and kadmin.local. It was kadmin that I would use on remote machines to export the keytab, rendering the original password useless. Thanks for the info. -A -- Anthony - http://messinet.com - http://messinet.com/~amessina/gallery 8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E signature.asc Description: This is a digitally signed message part. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa and cronjob
On Wed, 2012-11-14 at 00:22 -0600, Anthony Messina wrote: > On Wednesday, November 14, 2012 05:00:29 AM Simo Sorce wrote: > > On Tue, 2012-11-13 at 21:53 -0600, Anthony Messina wrote: > > > 1. Using automatic login with the lightdm display manager, I have it > > > run the > > > following script to remove any old Kerberos ccaches, then obtain a new > > > ticket > > > on behalf of the user, and set the appropriate permissions and > > > SELinux > > > context. Note that in this case, I echo the password to kinit -- If > > > I > > > exported a keytab, I would not be able to manually login with a known > > > password > > > if there were a problem. > > > > Just FYI, this is not strictly true, look at the -P, --password option > > of ipa-getkeytab > > Thanks. I didn't notice that option since I'd been using this method since > before I started using IPA. > > Is the password used to genterate a principle still usable after a keytab has > been exported? I seem to remember from my pre-IPA days of using a plain old > standalone MIT KDC that I couldn't use the password to authenticate after > they > keytab had been exported using kadmin. Again, I never really investigated > it, > but the password never seemed to work after the keytab was exported. If you ask kadmin to randomize the password, then you are basically *changing* the password at the time you export the keytab with a random one, so your *old* password won't work anymore and you do not know the new random one. But if you tell ipa-getkeytab to use a specific secret when generating the keytab that is what is used to generate the new keys, so whether you use pre-computed hashes in the keytab or manually regenerate them at kinit time using a password it makes no difference. Of course if you then change your password or get a new keytab you will change again keys so the repvious password/keytab won't work anymore. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa and cronjob
On 11/14/2012 07:22 AM, Anthony Messina wrote: On Wednesday, November 14, 2012 05:00:29 AM Simo Sorce wrote: On Tue, 2012-11-13 at 21:53 -0600, Anthony Messina wrote: 1. Using automatic login with the lightdm display manager, I have it run the following script to remove any old Kerberos ccaches, then obtain a new ticket on behalf of the user, and set the appropriate permissions and SELinux context. Note that in this case, I echo the password to kinit -- If I exported a keytab, I would not be able to manually login with a known password if there were a problem. Just FYI, this is not strictly true, look at the -P, --password option of ipa-getkeytab Thanks. I didn't notice that option since I'd been using this method since before I started using IPA. Is the password used to genterate a principle still usable after a keytab has been exported? I seem to remember from my pre-IPA days of using a plain old standalone MIT KDC that I couldn't use the password to authenticate after they keytab had been exported using kadmin. Again, I never really investigated it, but the password never seemed to work after the keytab was exported. Kadmin from original MIT Kerberos has to flavors: kadmin and kadmin.local. Only "kadmin.local" (which works locally on KDC) can export keytab without re-generating key (i.e. password). Network version - "kadmin" - have to re-generate key before each export. Simo can provide details about IPA get-keytab implementation. -- Petr^2 Spacek ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa and cronjob
On Wednesday, November 14, 2012 05:00:29 AM Simo Sorce wrote: > On Tue, 2012-11-13 at 21:53 -0600, Anthony Messina wrote: > > 1. Using automatic login with the lightdm display manager, I have it > > run the > > following script to remove any old Kerberos ccaches, then obtain a new > > ticket > > on behalf of the user, and set the appropriate permissions and > > SELinux > > context. Note that in this case, I echo the password to kinit -- If > > I > > exported a keytab, I would not be able to manually login with a known > > password > > if there were a problem. > > Just FYI, this is not strictly true, look at the -P, --password option > of ipa-getkeytab Thanks. I didn't notice that option since I'd been using this method since before I started using IPA. Is the password used to genterate a principle still usable after a keytab has been exported? I seem to remember from my pre-IPA days of using a plain old standalone MIT KDC that I couldn't use the password to authenticate after they keytab had been exported using kadmin. Again, I never really investigated it, but the password never seemed to work after the keytab was exported. -A -- Anthony - http://messinet.com - http://messinet.com/~amessina/gallery 8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E signature.asc Description: This is a digitally signed message part. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa and cronjob
On Tue, 2012-11-13 at 21:53 -0600, Anthony Messina wrote: > 1. Using automatic login with the lightdm display manager, I have it > run the > following script to remove any old Kerberos ccaches, then obtain a new > ticket > on behalf of the user, and set the appropriate permissions and > SELinux > context. Note that in this case, I echo the password to kinit -- If > I > exported a keytab, I would not be able to manually login with a known > password > if there were a problem. Just FYI, this is not strictly true, look at the -P, --password option of ipa-getkeytab :-) Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa and cronjob
On Tuesday, November 13, 2012 02:10:44 PM george he wrote:
> I have a cronjob run daily by an ipa user, which accesses nfs mounted data
> on the nfs server (another machine in the realm). The problem is when the
> user was away for a few days, his credential expired and the cronjob did
> not run until he came back and logged on to the system again. Then all
> halted cronjob from the past days started to run, which is not desired
> because all of them were doing the same thing. My question is: Can we keep
> the cronjob running when the user's credential is expired? If we cannot,
> then can we skip or kill all of the old cronjobs but not the most recent
> one?
This may not be exactly what you're looking for, but it might get you started.
I have a Kerberized NFSv4 setup with F17 machines here, two of which are used
only as MythTV frontend/backend machines. For each of these, I wanted
NFSv4/Kerberos mounted home directories with autologin AND the ability for the
frontend/backend machines to potentially stay on for more than 24 hours so I
do the following:
1. Using automatic login with the lightdm display manager, I have it run the
following script to remove any old Kerberos ccaches, then obtain a new ticket
on behalf of the user, and set the appropriate permissions and SELinux
context. Note that in this case, I echo the password to kinit -- If I
exported a keytab, I would not be able to manually login with a known password
if there were a problem.
#!/bin/bash
#
USERNAME="user1"
USERID="$(/usr/bin/id -u $USERNAME)"
PASSWORD="super_secret_password"
export KRB5CCNAME="FILE:/tmp/krb5cc_${USERID}"
/usr/bin/kdestroy -A -c ${KRB5CCNAME}
/usr/bin/echo "${PASSWORD}" | /usr/bin/kinit -r 604800s \
-c ${KRB5CCNAME##*:} ${USERNAME}
/bin/chown ${USERNAME}:${USERNAME} ${KRB5CCNAME##*:}
/usr/bin/chcon -t user_tmp_t ${KRB5CCNAME##*:}
2. I run the following user-specific cron job (/var/spool/cron/user1)
# For MythTV frontend hosts requiring access to NFSv4 filesystems exported
# with Kerberos v5, renew the Kerberos v5 ticket for the MythTV frontend user.
MAILTO=root
15 */4 * * */usr/bin/kinit -R
I'm guessing that if your user is an actual user, you may be able to do
something similar by ensuring that a renewable ticket was requested in the
first place, then issuing the cron task every so often.
I tried using the auto-renewal option of SSSD, but that didn't seem to work
for me. I didn't investigate why not, but I'm guessing it has something to do
with how a "user" logs in in the first place. My MythTV backend user, for
example, never actually logs in, but still needs Kerberos credentials to
access NFSv4 filesystems.
Now this will probably all change a bit in F18 with the switch to Kerberos DIR
ccaches placed under the /run/user/$UID portion of the filesystem, which is
not retained across reboots:
http://fedoraproject.org/wiki/Features/KRB5DirCache
http://fedoraproject.org/wiki/Features/KRB5CacheMove
I hope this helps in some small way. Also, if others have better ideas, I'd
love to hear them too!
-A
--
Anthony - http://messinet.com - http://messinet.com/~amessina/gallery
8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E
signature.asc
Description: This is a digitally signed message part.
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa and cronjob
On 11/13/2012 05:10 PM, george he wrote: > Hi all, > I have a cronjob run daily by an ipa user, which accesses nfs mounted > data on the nfs server (another machine in the realm). > The problem is when the user was away for a few days, his credential > expired and the cronjob did not run until he came back and logged on > to the system again. Then all halted cronjob from the past days > started to run, which is not desired because all of them were doing > the same thing. > My question is: Can we keep the cronjob running when the user's > credential is expired? If we cannot, then can we skip or kill all of > the old cronjobs but not the most recent one? > Thanks, > George > > > ___ > Freeipa-users mailing list > Freeipa-users@redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users Which cron jobs to keep and which ones to kill is really something you have to decide for yourself and script in your environment. There are several ways to overcome the issue though. Does the job really have to run as user? If so you might want to consider allowing SSSD to automatically renew the ticket on user behalf. See sssd-krb5 man page for details about the renewable tickets. Once the original authentication is conducted there is a period of the validity of the ticket but there is also a much longer period (by default a week or so) when the ticket can be renewed on behalf of the user. If the usual absence of users is less than say 10 days you can set a policy in IPA to allow renewable tickets for 10 days from the original authentication. Then the cron jobs would be able to run for at least 10 day until the tickets completely expire and can't be renewed. Keep in mind that by allowing the ticket to be longer lived you reduce the security of your environment as you increase the time the potential attacker can use to crack the ticket. However this kind of attack is unlikely but worth mentioning. If the job can be run under different identity then you have several options. You can create an account for the cron jobs to run and assign a keytab to it and provision it. Then the cron job can use this account and keytab to acquire tickets. One would have to periodically do kinit with this keytab as another cron job or use k5start which is not supported in RHEL but available upstream. Keep in mind that in future GSS proxy daemon would be able to automatically renew the tickets for such accounts on as needed basis. This functionality is planned for Fedora 19 and is waiting for MIT 1.11 to land in Fedora later this year or early next year. HTH -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
