William Muriithi via FreeIPA-users wrote:
> Hi  Wouter,
> On 11 August 2017 at 15:14,  <wouter.hummel...@kpn.com> wrote:
>> I've used shared keytabs before to create a loadbalanced squid instance.
>> This way you don't even need to use sticky balancing since all nodes that
>> have the key material will be able to decrypt TGSs for the shared service.
>> Be sure to use the -r option with ipa-getkeytab, otherwise the secret will
>> be reset. Alternatively you can just copy the keytab entries.
> Thank you. I got to test it this afternoon and have some follow up
> question/comment.  For one, I am not able to use the -r option/flag.
> Very odd, it don't even show up on the man page.  This is the error I
> am getting.
> [root@plutonium ~]# ipa-getkeytab -r -s  lithium.eng.example.com -p
> lsf/digitalmob.eng.example.com -k /etc/krb5.keytab
> Usage: ipa-getkeytab [-qP?] [-q|--quiet] [-s|--server Server Name]
>         [-p|--principal Kerberos Service Principal Name] [-k|--keytab
> Keytab File Name]
>         [-e|--enctypes Comma separated encryption types list]
> [--permitted-enctypes] [-P|--password]
>         [-D|--binddn DN to bind as if not using kerberos] [-w|--bindpw
> password to use if not using kerberos]
>         [-?|--help] [--usage]
> [root@plutonium ~]#

-r was added in 4.0.0 so I assume you are running 3.x.

> I ended up running it without the -r flag.  However, it didn't seem to
> reset the keytab.  At least I see all the service principles I
> expected. Do you know how I can verify that the secret hasn't been
> reset?
> ipa-getkeytab  -s  lithium.eng.example.com -p
> lsf/digitalmob.eng.example.com -k /etc/krb5.keytab
> [root@plutonium ~]# klist -ke  /etc/krb5.keytab

You run this on each host that has executed ipa-getkeytab and compare
the KVNO. If they are different the keys were changed.

Running without the retrieve option should reset the key.

> Lastly, it looks like the clients will be aware of all the servers,
> just not the load balancer. This don't look like a great idea to me.
> For example, if one server is down, the load balance would avoid
> sending traffic to it, but since the load balancer FQDN now resolve to
> all the IP addresses involved, the clients can connect to a system
> that is currently down.  How did you get around that?

I don't follow. The load balancer should be able to detect when one of
the servers it fronts is down.

FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

Reply via email to