samba - Oct 2022 - Upgrade AD DS from 4.9.5 -> 4.13.13, cannot resolve usernames on member server

On 28/10/2022 08:53, Harald Hannelius wrote:
> 
> On Thu, 27 Oct 2022, Rowland Penny via samba wrote:
> 
>> Moved from samba-technical:
>>
>> On 27/10/2022 11:44, Harald Hannelius wrote:
>>>
>>> On Thu, 27 Oct 2022, Rowland Penny via samba-technical wrote:
>>>> On 27/10/2022 10:57, Harald Hannelius via samba-technical
wrote:
>>>>>
>>>>> I upgraded my AD DS servers from Debian 10 to Debian 11
bullseye
>>>>> which also upgraded Samba from 4.9.5 to 4.13.13.
>>>>>
>>>>> Now I notice that I am unable to resolve usernames on the
member
>>>>> servers. I have only numbers in the processlist for
example.
>>>>> 'getent passwd "DOMAIN\harald"'
doesn't return anything.
>>>>>
>>>>> Did I miss something in the upgrade process?
>>>>
>>>> No idea, you haven't given us enough to work with.
>>>>
>>>> How did you upgrade your DC's ?
>>>
>>> apt-get upgrade && apt-get dist-upgrade
>>
>> Now that is generally okay for the base OS, but I wouldn't have
done
>> that. I would have created a new computer (in a VM or on bare metal) 
>> using Bullseye and the installed Samba from backports, joined this as 
>> a new DC, then once I was sure everything was okay, I would demote the 
>> old DC. There is just too big a jump between 4.9.5 and 4.13.x
> 
> I have to DS (DC) servers. You suggest to add a third, promote that, 
> demote the old ones and then promote them when they are upgraded?
The problem is that you have jumped several Samba versions at once and 
there will have been major changes at every 4.x.0 versions. By doing a 
dist-upgrade, you could have old versions of files left on disk and 
these could interfere with the way Samba works. It is best practise to 
create new DC's at every major upgrade, be that the OS or Samba. It will 
ensure that everything is fresh on every DC.

Normally I create a new computer running the latest Debian version and 
then install the latest version of Samba possible. I would then join 
this as a DC and then, once everything is definitely running okay, 
demote one of my old DC's, repeat for every other DC.
> 
> I would be nice if a dist-upgrade would fix everything :)
It might, but then it could make things worse.
> 
>>>> Did you upgrade them in place or did you create new DC's
and demote
>>>> the old ones ?
>>>
>>> In place.
>>
>> See above.
>>
>>>
>>>> What idmap backend are you using on the Unis domain members ?
>>>
>>> ?????idmap config domain:unix_primary_group = yes
>>> ?????idmap config domain:unix_nss_info = yes
>>> ?????idmap config domain:range = 500-4000000
>>
>> Was this domain upgraded from an old NT4-style domain ?
>>
>>> ?????idmap config domain:schema_mode = rfc2307
>>> ?????idmap config domain:backend = ad
>>> ?????idmap config * : range = 5000000-9000000
>>
>> The default '*' domain is meant for the well known SIDS (of
which
>> there are less than 200) and anything outside the 'DOMAIN'
domain, do
>> you really expect nearly 4 million connections from outside the domain
?
> 
> Almost all connections come from our other Windows AD domain.
Then that needs to be a 'trusted' domain with its own 'idmap
config' block.
> 
> I have been bitten hard a few times when tinkering with this so I am 
> reluctant to change anything that works :)
Problem is that things change and it stops working.

> 
> ========== DC (Samba 4.9.5): ===============> 
> # cat /etc/hostname
> sad1
>  ?# cat /etc/hosts
> 127.0.0.1??? localhost
> 193.167.33.91??? sad1.sad.arcada.fi??? sad1.arcada.fi??? sad1
> 2001:708:170:33::91??? sad1.sad.arcada.fi? sad1.arcada.fi? sad1
A DC can only be in ONE dns domain, so I strongly urge you to remove 
'sad1.arcada.fi'
> 
> # The following lines are desirable for IPv6 capable hosts
> ::1???? localhost ip6-localhost ip6-loopback
> ff02::1 ip6-allnodes
> ff02::2 ip6-allrouters
> # cat /etc/resolv.conf
> search sad.arcada.fi arcada.fi
> nameserver??? 2001:708:170:33::91
> nameserver??? 2001:708:170:33::92
Same again, you should remove arcada.fi
> # cat /etc/krb5.conf
> [libdefaults]
>  ????default_realm = SAD.ARCADA.FI
>  ????dns_lookup_realm = false
>  ????dns_lookup_kdc = true
> # testparm
> rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)
> WARNING: The "syslog" option is deprecated
> Registered MSG_REQ_POOL_USAGE
> Registered MSG_REQ_DMALLOC_MARK and LOG_CHANGED
> Load smb config files from /etc/samba/smb.conf
> rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)
> WARNING: The "syslog" option is deprecated
> Processing section "[netlogon]"
> Processing section "[sysvol]"
> Loaded services file OK.
> Server role: ROLE_ACTIVE_DIRECTORY_DC
> 
> Press enter to see a dump of your service definitions
> 
> # Global parameters
> [global]
>  ????dns forwarder = 2001:708:170:33::232 2001:708:170:33::246
>  ????logging = syslog
>  ????min domain uid = 500
I suggest that you change that '500' to '0', otherwise the
Administrator
to root mapping will be ignored.
>  ????passdb backend = samba_dsdb
>  ????realm = SAD.ARCADA.FI
>  ????server role = active directory domain controller
>  ????workgroup = SAD
>  ????rpc_server:tcpip = no
>  ????rpc_daemon:spoolssd = embedded
>  ????rpc_server:spoolss = embedded
>  ????rpc_server:winreg = embedded
>  ????rpc_server:ntsvcs = embedded
>  ????rpc_server:eventlog = embedded
>  ????rpc_server:srvsvc = embedded
>  ????rpc_server:svcctl = embedded
>  ????rpc_server:default = external
>  ????winbindd:use external pipes = true
>  ????idmap_ldb:use rfc2307 = yes
>  ????idmap config * : backend = tdb
>  ????map archive = No
>  ????vfs objects = dfs_samba4 acl_xattr
> 
> 
> [netlogon]
>  ????path = /var/lib/samba/sysvol/sad.arcada.fi/scripts
>  ????read only = No
> 
> 
> [sysvol]
>  ????path = /var/lib/samba/sysvol
>  ????read only = No
> 
> 
> ========== Domain member (also 4.9.5); ==============> 
> # cat /etc/hostname
> domus.sad.arcada.fi
I suggest you change that to just 'domus'
> 
>  ?# cat /etc/hosts
> 127.0.0.1??? localhost
> 193.167.33.91??? sad1.arcada.fi??? sad1
> 193.167.33.3??? domus.sad.arcada.fi??? domus
> 2001:708:170:33:3??? domus.sad.arcada.fi??? domus
I suggest you remove this line:  193.167.33.91    sad1.arcada.fi    sad1
The DC should be found via dns and that is pointing to the wrong dns 
domain anyway.
> 
> # The following lines are desirable for IPv6 capable hosts
> ::1???? localhost ip6-localhost ip6-loopback
> ff02::1 ip6-allnodes
> ff02::2 ip6-allrouters
> # cat /etc/resolv.conf
> domain sad.arcada.fi
> search sad.arcada.fi arcada.fi
I would remove 'arcada.fi
> nameserver??? 2001:708:170:33::232
> nameserver??? 2001:708:170:33::246
> nameserver 193.167.33.232
> nameserver 193.167.33.246
> (our resolvers have glue for the zones)
It doesn't really matter about the 'glue', all AD domain members
should
use a DC as their nameserver, mainly because the DC's are authoritative 
for the dns domain.
I suggest you point your AD clients at a DC, unless your other dns 
servers forward everything for the 'sad.arcadia.fi' to a DC.
> # cat /etc/krb5.conf
> [libdefaults]
> default_realm = SAD.ARCADA.FI
> dns_lookup_realm = false
> dns_lookup_kdc = true
> # testparm
> rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)
> Registered MSG_REQ_POOL_USAGE
> Registered MSG_REQ_DMALLOC_MARK and LOG_CHANGED
> Load smb config files from /etc/samba/smb.conf
> rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)
> Processing section "[homes]"
> Loaded services file OK.
> Server role: ROLE_DOMAIN_MEMBER
> 
> Press enter to see a dump of your service definitions
> 
> # Global parameters
> [global]
>  ????dedicated keytab file = /etc/krb5.keytab
>  ????disable spoolss = Yes
>  ????kerberos method = secrets and keytab
>  ????load printers = No
>  ????log file = /var/log/samba/log.%m
>  ????min domain uid = 500
Again change '500' to '0', or your user.map will not work.
>  ????printcap name = /dev/null
>  ????realm = SAD.ARCADA.FI
>  ????security = ADS
>  ????username map = /etc/samba/user.map
>  ????utmp = Yes
>  ????winbind enum groups = Yes
>  ????winbind enum users = Yes
I would turn the two lines above off, you do not need them and they just 
slow things down.
>  ????winbind refresh tickets = Yes
>  ????winbind use default domain = Yes
If you add a 'trusted' domain, you cannot use 'winbind use default 
domain = yes'

I said it was dns and it looks like I was correct.

Rowland

On Fri, 28 Oct 2022, Rowland Penny via samba wrote:
> Normally I create a new computer running the latest Debian version and then
> install the latest version of Samba possible. I would then join this as a
DC
> and then, once everything is definitely running okay, demote one of my old 
> DC's, repeat for every other DC.
So I installed a Debian 11 computer, and Samba 4.16.6 from 
bullseye-backports. I joined this to the AD and it looks like everything 
went OK. 'samba-tool ldapcmp' looks good, as does 'samba-tool drs
showrepl'.

Is there a way for me to actually test this "SAD3" new AD DC by for
instance
forcing one of my test fileservers to use only this computer as the DS?

If testing of SAD3 looks good, the the next logical step would be to demote 
SAD2 (as long as it's not primary), remove all traces of samba from it and 
upgrade that, install samba from backports and join that. Same for DS1, 
moving the primary role first.
>> Almost all connections come from our other Windows AD domain.
>
> Then that needs to be a 'trusted' domain with its own 'idmap
config' block.
I will get back to this, I promise. Sounds interesting, and I really need to 
learn more. If there only was more hours per day :/
>>  ????logging = syslog
>>  ????min domain uid = 500
>
> I suggest that you change that '500' to '0', otherwise the
Administrator to
> root mapping will be ignored.
But I do like it when we don't have a working Administrator account that has
access to all files :)
> If you add a 'trusted' domain, you cannot use 'winbind use
default domain =
> yes'
I will get back on this.


-- 

Harald Hannelius | harald.hannelius/a\arcada.fi | +358 50 594 1020