[Samba] Linux member joined to AD domain: No login with domain user possible, getent not working

[Paul Leiber]

Am 28.05.2025 um 09:49 schrieb Paul Leiber:
> Am 25.05.2025 um 13:14 schrieb Rowland Penny via samba:
>> 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.
> 
> Tested that (changing backend from ad to rid), no change.
> 
>> 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).
> 
> Success! I switched from a wireless connection to a wired connection, 
> and now getent passwd gives the correct output. Now I need to figure out 
> why this laptop has issues with the wireless connection. (Windows 
> systems inlcuding this same laptop connect just fine to AD on the same 
> SSID, and I even think that a linux installation on the same laptop 
> didn't have this issue in a previous installation, that's why I didn't 
> check a wired connection earlier.) I suspect some NetworkManager 
> configuration plays a role. I'll put an update to the list once I know 
> more.

Just a short update: Things seem to be working right now. But I still 
don't know what the exact root cause was.

As stated above, when connecting via ethernet, everything was working 
fine. While searching for a solution, I found out that getent passwd 
gives the correct output when connected via WiFi after the domain member 
had been connected via ethernet to the network and subsequently been 
disconnected (cable pulled). I suspect that a route for returning 
information to the member was missing when connecting via WiFi only, and 
connecting via ethernet creates this route, which persists even after 
disconnecting ethernet. (Don't know if this is plausible.)

Then I tried a different WiFi hardware (a USB device) to connect to the 
network. Everything was working as it should. Then I reset the original 
WiFi connection (with the builtin hardware) to default (back from static 
to DHCP), and then everything was working, I could use domain users to 
login to the domain member.

The most likely explanation seems to be that initially, the missing DC 
was the cause for the failures. While looking for a solution, I changed 
network settings to something that caused an additional issue (although 
I just set it to static, no idea what could have gone wrong). After 
fixing the missing DC issue, the networking issue persisted. Setting the 
network to DHCP fixed the networking issue.

Thanks again for you support,

Paul