[Samba] GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Server not found in Kerberos database)
Kees van Vloten
keesvanvloten at gmail.com
Mon Jun 24 13:14:59 UTC 2024
Please direct your messages to the samba mailinglist and not to my
personal mail!
On 24-06-2024 14:49, Omnis ludis - games wrote:
> I compared keytab and kvno in them on the server and on the client,
> everything is identical, increased the logging level to 3, as you
> said, and here is the log when authorizing a client from a neighboring
> domain
> {"timestamp": "2024-06-24T15:43:21.689360+0300", "type": "KDC
> Authorization", "KDC Authorization": {"version": {"major": 1, "minor":
> 0}, "status": "NT_STATUS_NO_SUCH_USER", thiserroris duetothe
> factthatthe idcommanddoesnotworkforthisuser, for example,
> idtest at RINT.TEST.COMwritesthatnosuchuser, ifyou knowhowthe
> idcommandworks, it maybecomeclearerwhywecan'tgetinformationaboutusers
The 'id' command will resolve the user through the password entry in
/etc/nsswitch.conf.
This is where winbind comes in to play, for passwd and group you should
have something similar to this in /etc/nsswitch.conf:
passwd: files systemd winbind
group: files systemd winbind
Both on your client (which is a fileserver) and on the DC.
I don't see a role for sssd on the fileserver, do remove it and just use
winbind (which is already configured in your /etc/samba/smb.conf on the
fileserver).
The DC has /etc/nsswitch.conf configured properly by default and that is
where you looked in the audit-auth.log. It looks like the local KDC is
trying to process the request for a user which it does not know, a user
which is probably defined at the other side of the trust.
I have no experience with trusts and cannot help with that.
- Kees.
>
> пн, 24 июн. 2024 г. в 15:01, Kees van Vloten <keesvanvloten at gmail.com>:
>
>
> On 24-06-2024 13:21, Omnis ludis - games wrote:
>> butthe encryptionthatis onsambathatis onthe clientis the
>> sameandthe keytabisonlyonthe clientandhowto understandif the
>> kvnois specifiedcorrectlyinit, you needto checkhowthekvnoof the
>> accountinthe sambadatabase?
>
> Get keytab on the client:
>
> sudo net ads keytab list # if you are using winbind or at least
> have 'net' installed
>
> or
>
> sudo klist -kte /etc/krb5.keytab # assuming this is where the
> keytab file is
>
>
> Export a one principal keytab from samba.
> Run on the DC with sufficient permissions:
>
> samba-tool domain exportkeytab -d 8 <temp-export-file>
> --principal=<one-principal-from-above-keytab>
> ktlist -kte <temp-export-file>
> # Compare kvno, local keytab must have at least the kvno that
> samba DC has
> # Also check encryption types between the two files and check them
> with settings in /etc/krb5.conf:
> # e.g. permitted_enctypes =
> rm <temp-export-file
>
>
> If there is a mismatch in kvno: use 'net ads keyab add' to update
> /etc/krb5.keytab or the sssd equivalent for that. Run it for each
> principal in the keytab.
>
> Also check that a password on the service / machine account is
> set. Without it ever set Kerberos authentication is not possible.
> For accounts created or updated by a domain-join this is not an
> issue as it will be set by the join.
>
> You can also get a clue from the auth-audit logging on the DC.
> Ensure you a line similar to this on the DC in /etc/samba/smb.conf
>
> [global]
> log level = 3 auth_json_audit:3@/var/log/samba/audit_auth.log
>
> Restart the DC service after modifying /etc/samba/smb.conf.
> Auth-audit logging on the server is more explicit than client-side
> logging in most cases.
>
> - Kees.
>
>>
>> пн, 24 июн. 2024 г. в 14:13, Kees van Vloten via samba
>> <samba at lists.samba.org>:
>>
>>
>> On 24-06-2024 12:42, Rowland Penny via samba wrote:
>> > On Mon, 24 Jun 2024 11:19:03 +0200
>> > Kees van Vloten via samba <samba at lists.samba.org> wrote:
>> >
>> >> On 24-06-2024 11:07, Omnis ludis - games via samba wrote:
>> >>> thank you
>> >>>
>> >>> пн, 24 июн. 2024 г. в 12:07, Rowland Penny via samba
>> >>> <samba at lists.samba.org
>> >>>> :
>> >>>> On Mon, 24 Jun 2024 11:52:17 +0300
>> >>>> Omnis ludis - games via samba <samba at lists.samba.org> wrote:
>> >>>>
>> >>>>> 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
>> >> This is a generic kerberos error, you can find numerous
>> pages with
>> >> suggestions on the net.
>> >>
>> >> I have seen errors like this one a few times (e.g. with
>> gssapi from
>> >> Apache), there are a lot of possible issues. Some I have
>> come across:
>> >>
>> >> - EncTypes must be set on the machine account in the DC
>> (and there
>> >> must be an overlap with the ones in the client's krb5.conf).
>> >>
>> >> - The machine password must be set on the account in the DC.
>> >>
>> >> - The kvno of the keytab entries on the client must match
>> with the
>> >> DC. Each time the password on the machine account is
>> changed a new
>> >> kvno is set on the keytab, so it must be exported to the
>> client again.
>> >>
>> >> Hopefully this helps :-)
>> >>
>> > It might be a password problem, but sssd is involved and,
>> from my
>> > perspective, if you are using 'security = ADS', then you
>> must run
>> > winbind and if winbind is running, then there is no point
>> to be also
>> > running sssd, winbind & sssd do virtually the same thing
>> and if sssd
>> > isn't setup correctly, then once a month it can stop
>> winbind in its
>> > tracks.
>> >
>> > Rowland
>> >
>> In this case it is an error generated by the Kerberos library
>> used by
>> the client (here sssd, I used apache back then). It tells us the
>> kerberos authentication is not working, not due to
>> authentication
>> failure but due to authentication not possible.
>>
>> From my experience the cause of this generic error is more
>> likely the
>> one-way trust or something with the service account /
>> computer account
>> (e.g. EncTypes mismatch, kvno mismatch) or /etc/krb5.conf
>> than it being
>> caused by sssd (although we can't rule it out).
>>
>> In this particular case I would bet on the one-way trust, as
>> that could
>> cause the kerberos ticket no to work properly and that
>> matches with what
>> the error expresses.
>>
>> - Kees.
>>
>>
>> --
>> To unsubscribe from this list go to the following URL and
>> read the
>> instructions: https://lists.samba.org/mailman/options/samba
>>
More information about the samba
mailing list