samba - May 2025 - Linux member joined to AD domain: No login with domain user possible, getent not working

Hi again,

I had to let this rest for some time, but now, there are new data points 
available.

Am 15.04.2025 um 10:16 schrieb Rowland Penny via samba:
> On Mon, 14 Apr 2025 23:13:25 +0200
> Paul Leiber via samba <samba at lists.samba.org> wrote:
> 
>> Am 14.04.2025 um 21:11 schrieb Rowland Penny via samba:
>>> On Mon, 14 Apr 2025 15:50:50 +0200
>>> Paul Leiber via samba <samba at lists.samba.org> wrote:
>>>
>>>> Dear Samba list,
>>>>
>>>> I am pulling my hair out over one linux machine (a laptop)
joined
>>>> to my Samba AD domain. On this machine, I can't use domain
users to
>>>> login. wbinfo -u shows AD users, getent passwd doesn't (no
output
>>>> is given). From other linux and windows machines, I can login
with
>>>> AD credentials and getent is working, so I assume that the
issue
>>>> is with that specific member.
>>>>
>>>> I can issue kerberos tickets on this machine for domain
members.
>>>>
>>>> If I use wbinfo --verbose -K INTERNAL\\user%password, the
output is
>>>> the following:
>>>> plaintext kerberos password authentication for [INTERNAL\user]
>>>> failed (requesting cctype: FILE)
>>>> wbcLogonUser(INTERNAL\user): error code was
NT_STATUS_LOGON_FAILURE
>>>> (0xc000006d)
>>>> error message was: The attempted logon is invalid. This is
either
>>>> due to a bad username or authentication information.
>>>> Could not authenticate user [INTERNAL\user%password] with
Kerberos
>>>> (ccache: FILE)
>>>>
>>>> You can find the sanitized samba info collected with the script
>>>> samba-collect-debug-info.sh below. I changed a lot of stuff
while
>>>> trying to fix this issue, the smb.conf therefore looks a bit
>>>> messy. I tried it with a copy of a smb.conf from a working
domain
>>>> member, but that didn't help.
>>>>
>>>
>>> I haven't seen the output from that script for a very long
time,
>>> but it all appears to be what is expected, so my first thought, is
>>> there a firewall getting in the way ?
>>
>> Yeah, I spotted the link to the script in one of Louis' old posts
>> related to my issue and thought that it looks handy...
>>
>> There is no firewall active on the DC. There is no firewall installed
>> on the member. There is a firewall on my router.
>>
>> If the WiFi connection is somehow botched due to NetworkManager (or
>> my limited understanding of NetworkManager, to be fair), it could be
>> possible that the firewall is blocking some traffic. However, I
don't
>> expect that the wired connection could also be blocked by the
>> firewall. I'll check anyway.
>>
>> 1. Could a firewall explain that wbinfo and getent behave
>> differently? Are different ports used for either program?
>> 2. Are there specific port(s) that I should monitor on the DC for
>> traffic from/to the member?
> 
> I have looked at the output of that script again and everything looks
> okay, even the time is correct, there should be no reason for 'getent
> passwd <USERNAME>' not to provide output if 'wbinfo -u | grep
> <USERNAME' does, unless either the Domain Users group doesn't
have a
> gidNumber inside the 10000-999999 range or the user doesn't have a
> uidNumber inside the same range.
> 
> What does 'wbinfo -i <USERNAME>' produce ?
failed to call wbcGetpwnam: WBC_ERR_DOMAIN_NOT_FOUND
Could not get info for user [user]

wbinfo --ping-dc on the other hand is successful.
> Otherwise, if you have other clients running the same OS etc that work,
> then I suggest you compare things until you find what the difference is.
I didn't find anything on this path yet.

However, here is a new angle: I have the suspicion that a temporarily 
missing DC has to do with my issue. I installed a second DC (for 
redundancy) on a Raspberry Pi some time ago. I had problems with the 
setup of the Raspberry Pi, therefore this DC2 was inactive for some time 
(several months). I was working under the assumption that a missing DC 
doesn't cause problems as long as another DC is available, therefore I 
didn't think of it much.

The first observation that brought me to my suspicion was the following: 
When using getent -u on the machine that has the original issues (no AD 
login possible), I could see in TCP traffic that DC1 was trying to 
contact DC2 (the missing one). I could also see that the output to 
getent -u takes some time after showing the local users until the AD 
users appeared. This looked like some timeout to me, which could be 
caused by waiting for the missing DC2.

The second observation came yesterday after updating various Debian 
packages (among others: Samba 4.22.1), including a reboot, on DC1. I 
suddenly could not access my shares anymore. (I want to make clear that 
I think this is a new error and not directly connected to the login 
issue.) The corresponding error in the samba log was "check_account: 
Failed to convert SID [SID] to a UID (dom_user:[user])". I also noticed 
again the unsuccessful contacts to DC2 from DC1. So I fixed the issue 
with the Raspberry Pi and spun up DC2 to test if this would resolve the 
issue with the share access, and it did.

Then I also checked if re-adding DC2 solves the login problems, but they 
still exist. However, the timeout between showing local users and AD 
users mentioned above is gone, that's why I think the login problem 
could also have to do with the missing DC.

Does that suspicion ring a bell with someone, and how could a missing DC 
be related to my login problems?

On a more general note: Is it really such a bad idea to have a DC which 
is not connected to the AD network for a longer period of time?

Thanks,

Paul

On Fri, 23 May 2025 20:42:23 +0200
Paul Leiber via samba <samba at lists.samba.org>
wrote:
> 
> However, here is a new angle: I have the suspicion that a temporarily 
> missing DC has to do with my issue. I installed a second DC (for 
> redundancy) on a Raspberry Pi some time ago. I had problems with the 
> setup of the Raspberry Pi, therefore this DC2 was inactive for some
> time (several months). I was working under the assumption that a
> missing DC doesn't cause problems as long as another DC is available,
> therefore I didn't think of it much.
> 
> The first observation that brought me to my suspicion was the
> following: When using getent -u on the machine that has the original
> issues (no AD login possible), I could see in TCP traffic that DC1
> was trying to contact DC2 (the missing one). I could also see that
> the output to getent -u takes some time after showing the local users
> until the AD users appeared. This looked like some timeout to me,
> which could be caused by waiting for the missing DC2.
> 
> The second observation came yesterday after updating various Debian 
> packages (among others: Samba 4.22.1), including a reboot, on DC1. I 
> suddenly could not access my shares anymore. (I want to make clear
> that I think this is a new error and not directly connected to the
> login issue.) The corresponding error in the samba log was
> "check_account: Failed to convert SID [SID] to a UID
> (dom_user:[user])". I also noticed again the unsuccessful contacts to
> DC2 from DC1. So I fixed the issue with the Raspberry Pi and spun up
> DC2 to test if this would resolve the issue with the share access,
> and it did.
> 
> Then I also checked if re-adding DC2 solves the login problems, but
> they still exist. However, the timeout between showing local users
> and AD users mentioned above is gone, that's why I think the login
> problem could also have to do with the missing DC.
> 
> Does that suspicion ring a bell with someone, and how could a missing
> DC be related to my login problems?
> 
> On a more general note: Is it really such a bad idea to have a DC
> which is not connected to the AD network for a longer period of time?
> 
It is a very bad idea to shutdown a DC for any length of time, a couple
of hours for maintenance is okay, but anything longer than this isn't
good. Every DC replicates to all other DC and there are dns records
required for each DC, DCs and clients use these dns records to find a
DC, but if the DC isn't there ??? There is also the possibility of
deleted records (that still exist on the turned off DC) coming back
when the turned off DC is turned on again.

If you are going to turn off a DC for any length of time, I suggest you
demote it.

The missing DC could well be your problem.

Rowland