Re: [Freeipa-users] sssd/pam login issues after upgrade to 2.2.1 on Fedora 17
On 11/12/2012 05:44 PM, Anthony Messina wrote: On Monday, November 12, 2012 09:51:14 AM Anthony Messina wrote: On Monday, November 12, 2012 09:17:17 AM Anthony Messina wrote: I also find that when I do a manual ldapsearch for the non-upgraded clients as follows: ldapsearch -x -D cn=directory manager -W -b cn=accounts,dc=messinet,dc=com ((objectClass=ipaHost)(fqdn=*)) dn the non-upgraded clients DO NOT appear in the list, but if I do the following: ldapsearch -x -D cn=directory manager -W -b cn=accounts,dc=messinet,dc=com ((objectClass=ipaHost)) dn the non-upgraded clients DO appear in the list. Somehow the addition of the fqdn=* in the filter ((objectClass=ipaHost)(fqdn=*)) prevents them from being displayed. There were no errors on any of the servers or clients during the upgrade. Your help is appreciated. I've tried to get this corrected all day without success. Thanks in advance. -A Hi, the SSSD depends on the fqdn attribute being present for the access control mechanism. Also, the SSSD searches the directory anonymously, so in order to get the same results, you should simply search the directory with anonymous bind. Can you check on the server how the host entries look like? For example: ipa host-show ds.messinet.com --all --raw Is the FQDN attribute present in the directory at all? Yes it is present. The entry seems to appear similar to other entries. I'm wondering if for some reason it wasn't indexed (I don't know much about indexing), but only the hosts that are re-enrolled after the update are displayed with the above search. I'm thinking this may be related to http://git.fedorahosted.org/cgit/freeipa.git/commit/?h=ipa-2-2id=ce11a7c0 e 22ee8f70e14c43419f20be70176fe8c Is there a way to re-index the fqdn attribute? While this may be a red herring, I also do not find in my ipaupgrade.log any attempt to re-index the fqdn attribute. These are the only entries for which tasks are created. 2012-11-11T13:25:39Z INFO Creating task to index attribute: memberuid 2012-11-11T13:25:45Z INFO Creating task to index attribute: memberOf 2012-11-11T13:25:51Z INFO Creating task to index attribute: memberHost 2012-11-11T13:25:57Z INFO Creating task to index attribute: memberUser 2012-11-11T13:26:03Z INFO Creating task to index attribute: ntUniqueId 2012-11-11T13:26:09Z INFO Creating task to index attribute: ntUserDomainId This in fact was the issue for SSSD: while indexes were added to 389 for the fqdn attribute, there was no index task created, so previous entries were not indexed, as new hosts were. Running the following fixed the issue and SSSD- based logins resumed immediately: ~]# cat fqdn_index_task.ldif dn: cn=indextask_fqdn, cn=index, cn=tasks, cn=config objectclass: top objectclass: extensibleObject cn: indextask_fqdn nsInstance: userRoot nsIndexAttribute: fqdn ~]# ldapadd -vvv -x -D cn=directory manager -W -f fqdn_index_task.ldif See https://fedorahosted.org/freeipa/ticket/3253 Thanks Anthony for this bug report! I added some info to the Trac ticket, but I will rather repeat here: This is indeed a bug in a code processing index updates. Index task is supposed to be created automatically for every new or updated index (i.e. the referred patch is OK), but it is unfortunately only processed in the update code path. To workaround the issue, one can either fire the index task manually as you did or simply run the FreeIPA LDAP upgrade procedure manually after freeipa-server package update. This will fire an index task too: # ipa-ldap-updater --upgrade # grep Creating task to index /var/log/ipaupgrade.log 2012-11-13T12:17:23Z INFO Creating task to index attribute: memberuid 2012-11-13T12:17:29Z INFO Creating task to index attribute: memberOf 2012-11-13T12:17:35Z INFO Creating task to index attribute: memberHost 2012-11-13T12:17:41Z INFO Creating task to index attribute: memberUser 2012-11-13T12:17:47Z INFO Creating task to index attribute: fqdn 2012-11-13T12:17:53Z INFO Creating task to index attribute: ntUniqueId 2012-11-13T12:17:59Z INFO Creating task to index attribute: ntUserDomainId After this command is run, the issue will be fixed. Martin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] ipa and cronjob
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
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
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 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
