List the keytab to pick the princiapl to use instead of guessing

[sssd-bot]

Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/781

• Created at 2011-01-21 17:01:31 by simo
• Closed as Fixed
• Assigned to jzeleny
• Associated bugzillas
  • https://bugzilla.redhat.com/show_bug.cgi?id=785881

---

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

Comments

---

Comment from dpal at 2011-01-21 17:29:47

Nice! I think it belongs to 1.6.

---

Comment from dpal at 2011-01-27 15:14:59

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.6.0

---

Comment from dpal at 2011-02-07 15:07:35

Related to #700

owner: somebody => jzeleny

---

Comment from jzeleny at 2011-03-11 14:27:12

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

---

Comment from dpal at 2011-03-11 15:40:34

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.

---

Comment from jzeleny at 2011-03-11 15:54:30

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

---

Comment from simo at 2011-03-13 21:17:11

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.

---

Comment from jzeleny at 2011-03-28 10:03:23

Fields changed

status: new => assigned

---

Comment from sgallagh at 2011-05-02 20:51:50

Fixed by
- cfd79b9
- e81a816
- e2be782

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

---

Comment from sgallagh at 2012-01-30 21:19:20

Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=785881

rhbz: => [https://bugzilla.redhat.com/show_bug.cgi?id=785881 785881]

---

Comment from simo at 2017-02-24 15:07:03

Metadata Update from @Simo:

• Issue assigned to jzeleny
• Issue set to the milestone: SSSD 1.6.0