SSSD problem one-way trust GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Server not found in Kerberos database)

[Omnis ludis - games]

Good afternoon, please tell me there is such an infrastructure windows
domain and samba domain between them, one-sided external outgoing trust
relationships are set up, so that users from the windows domain can freely
enter the samba domain, I entered the client into the samba domain and all
users from the samba domain can safely pass to this client, but that's not
the task of users they do not want to authenticate from the windows domain
in any way when I try to log in to a client from the samba domain under
them, I get the following error in sssd on the client, GSSAPI Error:
Unspecified GSS failure.  Minor code may provide more information (Server
not found in Kerberos database), do I understand correctly that this works
like this, the client accesses the samba domain controller, since there is
no given user in samba, the request is redirected to the windows domain
controller and that in turn must provide information about this to users
from its database kerberos? but for some reason this does not happen, does
anyone have at least some information on this error, I have already tried
many different scenarios and can not log in as a user in any way, as if
samba does not process information correctly, while if you build a two-way
trusting relationship, then everything works as it should

[Spike White]

Ethel,

Also be careful with sssd and one-way trusts.

We find that sssd discovers and reports *ALL* one-way trusts, even ones
that go the wrong way.    That is, in our company there's a lot of test and
lab AD domains that trust the main domain -- but the main AD domain doesn't
trust these "cowboy" AD domains.  (and rightly so.)

As a consequence, we have to put the following line in our sssd.conf file:

ad_enabled_domains = amer.company.com, apac.company.com, emea.company.com,
japn.company.com company.com

That line is basically saying -- "I don't care what yahoo AD domains you
discover -- only deal with these specific AD domains."

And then later in the domain section, we'll put in a
domain_resolution_order line.  In order to tell sssd in which order to
search these AD domains (for users and groups).

Spike.

On Mon, Feb 17, 2025 at 1:54 PM Ethel Andino via sssd-users <
[e-mail]> wrote:
> I ran into a problem trying to set up GSSAPI authentication. Everything
> went smoothly on the test bench, but when we moved it to production, I hit
> an “Unspecified GSS failure” error.
>
> I spent nearly two days trying to debug it without any luck. It turned out
> that the client was trying to authenticate through Samba while the accounts
> were in a Windows domain. I went through a bunch of standard fixes like
> checking DNS and reconfiguring services, but nothing did the trick.
>
> Then, out of nowhere, I found a helpful resource (
> andersenlab.com/services/artificial-intelligence/consulting ), which had
> some great info on integrating these kinds of systems. The spinics.net
> forum (https://www.spinics.net/lists/samba/msg183234.html) was also a
> lifesaver; they had a similar case where someone suggested I check the SSSD
> logs. I noticed a weird pattern in the errors and, after some tweaks with
> the two-way trust setup, everything finally worked!
>
> So it's my ready-made checklist for such situations:
> Check out the SSSD logs to get more info on the error. This will help
>
> you figure out why the authorization isn't working.
> 2) Make sure your DNS settings are set up right to resolve the domain
> controller names.
> 3) Think about setting up a temporary two-way trust relationship to see if
> that helps with authorization.
> --
> _______________________________________________
> sssd-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/[e-mail].o...
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue