Thanks Simo, Unfortunately CNAMES will not work for me. When I connect to one of my services (Usually HTTP, SSH, or SQL) I need to connect on their Virtual IP rather then the hosts IP. Cnames would change the behavior of this and only connect me to they system IP rather then then the service its self.
On Sun, Feb 3, 2013 at 7:11 PM, Simo Sorce <sso...@redhat.com> wrote: > ----- Original Message ----- >> Thanks for your replys. >> >> I have tried this option with no success. >> GSSAPIStrictAcceptorCheck no >> >> After trouble shooting some more I think this probably does not have >> to do with sssd at this point but more in krb5. >> >> "In other words, are all the clients you are logging to in the domain >> .mydomain.com and Kerberos realm MYDOMAIN.COM?" >> >> I'm guessing this is where my problem is. >> >> Yes My Active Directory domain is mydomain.com >> and all the hosts are host.mydomain.com >> And I do have a mapping for .mydomain.com Kerberos realm MYDOMAIN.COM >> >> I think the issue is possibly sub-domains. >> Where my services I would like to ssh to are >> service.s.prod.mydomain.com or service.s.dev.mydomain.com >> I did a test and cnamed my services to the FQDN of the host and >> GSSAPI >> auth worked. >> >> So, It looks like I need to play around with mapping subdomains and >> possible dns for this to work the way I need it to. >> >> I appreciate your replys. > > Using CNAMEs is the correct way to go. > In GSSAPI a CNAME is resolved into an A name first and then a ticket for > the resulting host/A-name is taken if host/A-name = host/ownname where > ownname is the name actually used to fetch a keytab for the host then all > works as you have ticket that the host can decrypt as it has the right key. > > Instaed if you try to round robin A-names then host/A-name is used to obtain > a ticket but your host's own keys are not host/ownanme where > host/owname != host/A-name then you try to contact the machine with a ticket > it has no key to decrypt, as the machine has the key for host/ownname not > host/A-name > > > HTH, > Simo. > >> On Fri, Feb 1, 2013 at 6:00 AM, John Hodrien >> <j.h.hodr...@leeds.ac.uk> wrote: >> > On Fri, 1 Feb 2013, Sumit Bose wrote: >> > >> >> I guess this might be a limitation of sshd. iirc it will not use >> >> all >> >> tickets from the keytab but only the one that matches >> >> host/fully.qualified.host.name where the fully.qualified.host.name >> >> is >> >> determined with uname() or gethostname(). This means by default a >> >> system >> >> is only accessible with one fully qualified name with ssh and >> >> GSSAPI. >> > >> > >> > Is this relevant? >> > >> > GSSAPIStrictAcceptorCheck >> > Determines whether to be strict about the identity of >> > the >> > GSSAPI >> > acceptor a client authenticates against. If “yes” then >> > the >> > client >> > must authenticate against the host service on the >> > current host- >> > name. If “no” then the client may authenticate against >> > any ser- >> > vice key stored in the machine’s default store. This >> > facility >> > is >> > provided to assist with operation on multi homed >> > machines. The >> > default is “yes”. Note that this option applies only >> > to >> > protocol >> > version 2 GSSAPI connections, and setting it to “no” >> > may only >> > work with recent Kerberos GSSAPI libraries. >> > >> > jh >> > _______________________________________________ >> > sssd-devel mailing list >> > sssd-devel@lists.fedorahosted.org >> > https://lists.fedorahosted.org/mailman/listinfo/sssd-devel >> > >> _______________________________________________ >> sssd-devel mailing list >> sssd-devel@lists.fedorahosted.org >> https://lists.fedorahosted.org/mailman/listinfo/sssd-devel >> > > -- > Simo Sorce * Red Hat, Inc. * New York > _______________________________________________ > sssd-devel mailing list > sssd-devel@lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/sssd-devel _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
