On 09/19/2014 04:03 PM, Walid wrote:
Thank you all, will investigate the requirements of host keytabs, and if there is a way around it by having it shared but secure for our context.


Couple hints.

1. If you have a keytab stashed and the system was rebuilt you can now rerun ipa-client-install using this keytab to get a new one and configure the client system. It can run and then die but if you store the keytab after running ipa-client-install you would be able to revive it next time 2. In 4.1 you will be able to retrieve same keytab using ipa-getkeytab command. It is implemented to allow clusters that have to share the same key but it might be applicable to your use case too.

Thanks
Dmitri


On 18 September 2014 23:04, Dmitri Pal <d...@redhat.com <mailto:d...@redhat.com>> wrote:

    On 09/18/2014 10:12 AM, Walid A. Shaari wrote:
    Hi,

    we are going to have a use case of diskless HPC clients that will
    use the IPA for lookups, I was wondering if i can get rid of the
    state-fulness of the client configuration as much as possible as
    it is more of a cattle than pets use case. that is i do not need
    to know that the client is part of the domain, no need to enroll
    a node with a certificate. and services will be mostly hpc mpi
    and ssh, not required to have an SSL certificate for secure
    communication. is it possible to get rid of the client
    certificate and the requirements for clients to enroll? or there
    are other uses for the certificate that i am not aware of ?

    regards

    Walid


    I think the main problem is making sure that the client can
    connect to IPA server.
    You can elect to not use ipa-client and just copy configuration
    files. The problem is that SSSD requires some type of the
    authentication to get to IPA as a host to do the lookups.
    So this connection must be authenticated. Since you want it to be
    stateless you do not want to manage keys or certs the only option
    (which I really do not like) is to use bind password in a file for
    LDAP connection. You would probably use the same unprivileged
    account for this bind. However when we get to 4.x you would need
    to adjust permissions on the server side to make sure that proper
    read permissions are granted. Having a password in a file is a
    security risk so make sure it is not leaked.

-- Thank you,
    Dmitri Pal

    Sr. Engineering Manager IdM portfolio
    Red Hat, Inc.


    --
    Manage your subscription for the Freeipa-users mailing list:
    https://www.redhat.com/mailman/listinfo/freeipa-users
    Go To http://freeipa.org for more info on the project




--
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project

Reply via email to