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

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

Am 23.05.2025 um 21:43 schrieb Rowland Penny via samba:
> 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.
Thanks for the information. Will of course do next time. From what I 
could see, both DCs are running smoothly, I didn't notice any errors in 
logs.
> The missing DC could well be your problem.
Meanwhile (with both DC1 and the formerly missing DC2 online), I 
unjoined the domain, stopped samba on the member, deleted samba .tdb 
cache files, and rejoined using net ads join --no-dns-updates -U 
administrator, then I started samba services.

The output of the attempt to join showed different errors this time:

gensec_gse_client_prepare_ccache: Kinit for MEMBER$@SAMDOM.EXAMPLE.COM 
to access ldap/DC1.SAMDOM.EXAMPLE.COM failed: Client not found in 
Kerberos database: NT_STATUS_LOGON_FAILURE
gensec_gse_client_prepare_ccache: Kinit for MEMBER$@SAMDOM.EXAMPLE.COM 
to access cifs/DC1.SAMDOM.EXAMPLE.COM failed: Client not found in 
Kerberos database: NT_STATUS_LOGON_FAILURE
Using short domain name -- SAMDOM
Joined 'MEMBER' to dns domain 'SAMDOM.EXAMPLE.COM'

I still am not getting information on domain users with getent passwd. 
wbinfo -u shows all domain users.

Do the kerberos errors point to new things I can try to solve this issue?

Paul