#781 List the keytab to pick the princiapl to use instead of guessing
Closed: Fixed None Opened 11 years ago by simo.

Apparently, at the moment, we try to construct the principal name for the
local host name and then hope it is matched in the keytab to get a TGT for
operations.

It would be less wasteful to instead open the keytab and list the principals
found in there, then pick the appropriate name in the right form.

This way we will be less prone to failure for misconfigured hosts.
As long as the keytab has a key sssd will always be able to find a key to
use regardless of what the machine thinks is the hostname (which sometimes can
be wrong due to not infrequent /etc/hosts or other misconfigurations)

This would also allow to use native AD principal names for computers (in the
form of FOOBAR$@REALM) for machines joined to an AD domain via samba tools,
without having to add any explicit configuration for it. If it is found give
precedence to the AD form otherwise look for host/fqdn form.

HTH


Nice! I think it belongs to 1.6.

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.6.0

Related to #700

owner: somebody => jzeleny

I don't understand one thing here. What should be the algorithm for picking "the right principal/key"? You write that there should be no need for additional configuration, so what exactly do you propose?

description: Apparently, at the momnent, we try to construct the principal name for the
local host name and then hope it is matched in the keytab to get a TGT for
operations.

It would be less wasteful to instead open the keytab and list the principals
found in there, then pick the appropriate name in the right form.

This way we will be less prone to failure for misconfgured hosts.
As long as the keytab has a key sssd will always be able to find a key to
use regardless of what the machine thinks is the hostname (which sometimes can
be wrong due to not infrequent /etc/hosts or other misconfigurations)

This would also allow to use native AD principal names for computers (in the
form of FOOBAR$@REALM) for machines joined to an AD domain via samba tools,
without having to add any explicit configuration for it. If it is found give
precedence to the AD form otherwise look for host/fqdn form.

HTH => Apparently, at the moment, we try to construct the principal name for the
local host name and then hope it is matched in the keytab to get a TGT for
operations.

It would be less wasteful to instead open the keytab and list the principals
found in there, then pick the appropriate name in the right form.

This way we will be less prone to failure for misconfigured hosts.
As long as the keytab has a key sssd will always be able to find a key to
use regardless of what the machine thinks is the hostname (which sometimes can
be wrong due to not infrequent /etc/hosts or other misconfigurations)

This would also allow to use native AD principal names for computers (in the
form of FOOBAR$@REALM) for machines joined to an AD domain via samba tools,
without having to add any explicit configuration for it. If it is found give
precedence to the AD form otherwise look for host/fqdn form.

HTH

Replying to [comment:4 jzeleny]:

I don't understand one thing here. What should be the algorithm for picking "the right principal/key"? You write that there should be no need for additional configuration, so what exactly do you propose?

Open keytab and list the principals and pick the principal that is there. For each principal try to match it to the host name using regular expression or substring search. The host name should be a substring of the principal found in the keytab. With the right matching we would be able to support both AD and MIT formats.

I think this is what Simo proposes and I agree with him.

Thanks Dmitri, I have much better understanding of this now. I'll make a conceptual patch and we can discuss eventual small modifications afterwards.

Open keytab and list the principals and pick the principal that is there. For each principal try to match it to the host name using regular expression or substring search. The host name should be a substring of the principal found in the keytab. With the right matching we would be able to support both AD and MIT formats.

I think this is what Simo proposes and I agree with him.

Almost but not quite.

What I am saying is this:

1. open the keytab and list the principals.

2. search for a principal of this form first:
  FOOBAR$@REALM.NAME

  this form is used by windows, and used short machine name + $ + @REALM

  If this is found it means this machine has been joined to an AD domain, so use this principal name as the credential to use to connect and auth to the LDAP server in GSSAPI.

3. search for a host Service Principal Name:
  host/any.f.q.d.n@ANY.REALM.NAME

  If any principal matches host/*@* then use this one to auth to the LDAP server.

  Do *not* try to match the machine hostname to the fqdn, we are scanning exactly to avoid relying on the correct hostname being available through gethostname()

4. If none of the above matches, pick the first principal in the keytab and try with that one.

Skip all of the above if a specific principal name override is set with the ldap_sasl_authid option.

Fields changed

status: new => assigned

Fixed by
- cfd79b9
- e81a816
- e2be782

component: SSSD => Kerberos Provider
patch: => 0
resolution: => fixed
status: assigned => closed

Metadata Update from @simo:
- Issue assigned to jzeleny
- Issue set to the milestone: SSSD 1.6.0

5 years ago

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/1823

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Login to comment on this ticket.

Metadata