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

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

On Sun, 25 May 2025 11:39:19 +0200
Paul Leiber via samba <samba at lists.samba.org> wrote:

> 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
Unless you have pre-created the required records in AD, those errors
are to be expected if you use '--no-dns-updates'.
> 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.
For getent to show users & groups, a few things need to be configured:

The computer needs to be joined to the AD domain, this appears to be
correct.
You need to have a correctly configured smb.conf, this appears to be
correct.
You need to have libnss-winbind & libpam-winbind installed, these
appear to be installed.
The 'passwd' & 'group' lines in /etc/nsswitch.conf need to
contain
'winbind', which they do.

Finally this leaves, because you are using the 'ad' idmap config
backend, the rfc2307 attributes in AD. Every user, you want visible
to Unix, must have a uidNumber attribute containing a number inside the
range set in your smb.conf (in your case 10000-999999), any uidNumber
attributes outside that range will be ignored. Every group, you want
visible to Unix, must have a gidNumber attribute containing a number
inside the same range, again, any gidNumber attribute outside the range
will be ignored. It is very important that Domain Users has a
gidNumber, without that gidNumber, all AD users & groups will be
invisible to Unix.

There is an easy way to check the connection to AD, change 'idmap
config INTERNAL:backend = ad' to 'idmap config INTERNAL:backend =
rid'
and restart Samba. If you then get a response from 'getent passwd
USERNAME', then it is a problem with the rfc2307 attributes in AD, if
you still get nothing then you may have connection problems (firewall
etc).

Rowland