On 04/12/2013 11:04 AM, Jason Bishop wrote:
Headnode has keytab, there are also 3 login nodes
and they have keytab too. then there are 100 compute nodes
which presently do not.
anonymous is clever idea, but i was hoping to
instrument compute nodes such that my user and group filters
on headnode sssd config would be in effect. IE the users and
groups the headnode sees the computes also see.
of the two the groups is the tricky one as i need
special permissions on my host keytab to actually get that
data (its not avail anonymously).
thank you for the help i would really like to get
So do I get it right: you do not want keytabs to be on the nodes but
on the other hand you want the nodes to be able to get the same
information so they need to be authenticated?
I have a stupid idea...
How about sharing the kerberos ticket cache in some way between the
I do not know how to do it best to not create security holes.
Have a cron job to copy around or if there is some shared area in
the cluster store the ticket cache there and point nodes to it?
In this case cluster nodes would not be able to initiate the
communication until the headnode has a ticket. I do not know how
SSSD would behave in this situation though...
May be to trick SSSD one can create a keytab with dummy key. That
would probably cause some failure to connect if tried and SSSD would
go offline but next time it tries it should see a ready to use
kerberos ticket in the shared cache and just use it.
sssd-users mailing list
Sr. Engineering Manager for IdM portfolio
Red Hat Inc.
Looking to carve out IT costs?