Learn more about these different git repos.
Other Git URLs
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.
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)
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.
Replying to [comment:4 jzeleny]:
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.
status: new => assigned
Fixed by - cfd79b9 - e81a816 - e2be782
component: SSSD => Kerberos Provider patch: => 0 resolution: => fixed status: assigned => closed
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]
Metadata Update from @simo: - Issue assigned to jzeleny - Issue set to the milestone: SSSD 1.6.0
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.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Login to comment on this ticket.