I have jammy packages in the test ppa as well. I just performed my test plan with all of the plucky, noble, and jammy packages, and it passed. I'm preparing branches for peer review now.
** Description changed: [ Impact ] * An explanation of the effects of the bug on users and justification for backporting the fix to the stable release. * In addition, it is helpful, but not required, to include an explanation of how the upload fixes this bug. [ Test Plan ] + Below is a test plan that satisfied the SRU criteria, but affected users are also invited to deploy the proposed packages to affected members servers in their existing networks to confirm the fix. + + The test plan below has to be carried out regardless of the above. # Deploy Windows Server with Active Directory, or use an existing domain. - # Apply all updates, and make sure you have KB5062553 applied - # For this test case, the domain is assumed to be EXAMPLE.COM. Many other - # assumptions are made, like the uid/gid range in the idmap_ad configuration. + # Apply all updates. In particular, make sure you have KB5062553 applied. + + # As described, this test plan makes certain assumptions: + # - active directory domain is EXAMPLE.COM + # - IP of the AD server is 192.168.1.10/24 + # - AD server is also acting as DNS (default with an AD deployment) + # - gateway of the network is 192.168.1.1/24 + # - uid/gid ranges for the idmap_ad backend as defined in the given smb.conf # Please adapt to your scenario if using an existing AD deployment. - # Launch lxc VM in the same network as the AD server (??? not needed - ???) - + # Iterate over the ubuntu releases being tested export RELEASE=plucky lxc launch ubuntu-daily:$RELEASE member-test --vm # From here on, these commands are executed inside that vm lxc shell member-test # configure networking if needed. For example, for a fixed IP: cat > /etc/netplan/50-cloud-init.yaml <<EOF network: - version: 2 - ethernets: - enp5s0: - dhcp4: false - addresses: [192.168.1.103/24] - nameservers: - search: [example.com] - addresses: [192.168.1.10] - routes: - - to: default - via: 192.168.1.1 + version: 2 + ethernets: + enp5s0: + dhcp4: false + addresses: [192.168.1.103/24] + nameservers: + search: [example.com] + addresses: [192.168.1.10] + routes: + - to: default + via: 192.168.1.1 EOF chmod 0600 /etc/netplan/50-cloud-init.yaml netplan apply # Depending on which packages are updated here, you might be logged out. Just # run "lxc shell" again if that happens. apt update && apt dist-upgrade -y apt install -y samba winbind libnss-winbind libpam-winbind # EXTRA STEP FOR JAMMY ONLY # add winbind to the end of the passwd and group lines in /etc/nsswitch.conf. # This command should do it: sed -i -r 's,(^(passwd:|group:)[[:blank:]]+.*)$,\1 winbind,' /etc/nsswitch.conf # But please check that these lines in /etc/nsswitch.conf look like shown below: passwd: files systemd winbind group: files systemd winbind # END OF JAMMY-ONLY EXTRA STEPS - # Write this to /etc/samba/smb.conf: cat > /etc/samba/smb.conf <<EOF # Global parameters [global] - kerberos method = secrets and keytab - log file = /var/log/samba/log.%m - logging = file - map to guest = Bad User - max log size = 1000 - panic action = /usr/share/samba/panic-action %d - realm = EXAMPLE.COM - security = ADS - server role = member server - server string = %h server (Samba, Ubuntu) - workgroup = EXAMPLE - idmap config * : backend = tdb - idmap config * : range = 3000-7999 - idmap config example:backend = ad - idmap config example:schema_mode = rfc2307 - # 10.000 - 999.999 - idmap config example:range = 10000-999999 - idmap config example:unix_nss_info = no - - template shell = /bin/bash - template homedir = /home/%U - - vfs objects = acl_xattr - map acl inherit = yes - store dos attributes = yes - + kerberos method = secrets and keytab + log file = /var/log/samba/log.%m + logging = file + map to guest = Bad User + max log size = 1000 + panic action = /usr/share/samba/panic-action %d + realm = EXAMPLE.COM + security = ADS + server role = member server + server string = %h server (Samba, Ubuntu) + workgroup = EXAMPLE + idmap config * : backend = tdb + idmap config * : range = 3000-7999 + idmap config example:backend = ad + idmap config example:schema_mode = rfc2307 + # 10.000 - 999.999 + idmap config example:range = 10000-999999 + idmap config example:unix_nss_info = no + + template shell = /bin/bash + template homedir = /home/%U + + vfs objects = acl_xattr + map acl inherit = yes + store dos attributes = yes [printers] - browseable = No - comment = All Printers - create mask = 0700 - path = /var/tmp - printable = Yes + browseable = No + comment = All Printers + create mask = 0700 + path = /var/tmp + printable = Yes [print$] - comment = Printer Drivers - path = /var/lib/samba/printers + comment = Printer Drivers + path = /var/lib/samba/printers EOF - - # Join the domain (you may get an error about failing to update the DNS entry, that's irrelevant for this test) + # Join the domain (you may get an error about failing to update the DNS + entry, that's irrelevant for this test) net ads join -U Administrator # restart samba services systemctl restart smbd nmbd winbind # Test the join with these two commands: wbinfo -t net ads testjoin # Create a linux user in the domain with the following details: First name: Questing Last name: Ubuntu User logon name: questing UNCHECK: user must change password at next logon In the attribute editor tab (enable "Advanced features" in the View menu), locate the following attributes and fill them in as shown: uidNumber: 10002 - - # Check that the user is in the output of this command (careful: if using an existing AD domain, it might be best to not run this as there could be thousands of users): + # Check that the user is in the output of this command (careful: if + using an existing AD domain, it might be best to not run this as there + could be thousands of users): wbinfo -u # Now for the actual bug: flush the cache, and run the id command shown. If using the packages with the bug, the command will fail. If using the fixed packages, it will return user and group information: net cache flush id quest...@example.com # Failing case: id: ‘quest...@example.com’: no such user # Good case (output may vary depending on how the user was created; important point is that the user is "known"): uid=10002(EXAMPLE\questing) gid=10000(EXAMPLE\domain users) groups=10000(EXAMPLE\domain users),3001(BUILTIN\users) - # In the failure case, you can also increase debugging of winbind with this command: smbcontrol winbind debug 4 - And then see failures in the /var/log/samba/log.winbindd log file: + # Note the debug level change above is not permanent, and will be lost + if the service is restarted. + + # And then see failures in the /var/log/samba/log.winbindd log file: ==> /var/log/samba/log.winbindd <== [2025/07/21 17:45:35.313189, 0] source3/winbindd/winbindd_dual.c:1964(winbindd_sig_term_handler) - Got sig[15] terminate (is_parent=1) + Got sig[15] terminate (is_parent=1) [2025/07/21 17:45:35.359569, 0] source3/winbindd/winbindd.c:1441(main) - winbindd version 4.19.5-Ubuntu started. - Copyright Andrew Tridgell and the Samba Team 1992-2023 + winbindd version 4.19.5-Ubuntu started. + Copyright Andrew Tridgell and the Samba Team 1992-2023 [2025/07/21 17:46:06.689406, 0] source4/lib/messaging/messaging.c:188(debug_imessage) - debug_imessage: INFO: Remote set of debug to `4' (pid 2814 from pid 2850) + debug_imessage: INFO: Remote set of debug to `4' (pid 2814 from pid 2850) [2025/07/21 17:46:06.689475, 3] lib/util/debug_s3.c:97(debug_message) - INFO: Remote set of debug to `4' (pid 2814 from pid 2850) + INFO: Remote set of debug to `4' (pid 2814 from pid 2850) [2025/07/21 17:46:17.280262, 3] source3/winbindd/winbindd_misc.c:355(winbindd_interface_version) - winbindd_interface_version: [nss_winbind (2858)]: request interface version (version = 32) + winbindd_interface_version: [nss_winbind (2858)]: request interface version (version = 32) [2025/07/21 17:46:17.280432, 3] source3/winbindd/winbindd.c:497(process_request_send) - process_request_send: [nss_winbind (2858)] Handling async request: GETPWNAM + process_request_send: [nss_winbind (2858)] Handling async request: GETPWNAM [2025/07/21 17:46:17.280448, 3] source3/winbindd/winbindd_getpwnam.c:59(winbindd_getpwnam_send) - [nss_winbind (2858)] Winbind external command GETPWNAM start. - Query username 'quest...@example.com'. + [nss_winbind (2858)] Winbind external command GETPWNAM start. + Query username 'quest...@example.com'. [2025/07/21 17:46:17.569589, 3] source3/winbindd/wb_dsgetdcname.c:135(wb_dsgetdcname_recv) - Failed for example with NT_STATUS_NO_SUCH_DOMAIN. + Failed for example with NT_STATUS_NO_SUCH_DOMAIN. [2025/07/21 17:46:17.569658, 1] source3/winbindd/wb_sids2xids.c:765(wb_sids2xids_recv) - Failed with NT_STATUS_NO_SUCH_DOMAIN. + Failed with NT_STATUS_NO_SUCH_DOMAIN. [2025/07/21 17:46:17.569686, 1] source3/winbindd/winbindd_getpwnam.c:142(winbindd_getpwnam_recv) - Could not convert sid S-1-5-21-2226137316-1638043825-1947191812-1111: NT_STATUS_NO_SUCH_DOMAIN + Could not convert sid S-1-5-21-2226137316-1638043825-1947191812-1111: NT_STATUS_NO_SUCH_DOMAIN [2025/07/21 17:46:17.569698, 3] source3/winbindd/winbindd.c:564(process_request_done) - process_request_done: [nss_winbind(2858):GETPWNAM]: NT_STATUS_NO_SUCH_DOMAIN + process_request_done: [nss_winbind(2858):GETPWNAM]: NT_STATUS_NO_SUCH_DOMAIN [2025/07/21 17:46:17.569856, 1] source3/winbindd/wb_queryuser.c:123(wb_queryuser_got_uid) - wb_sids2xids_recv() failed with NT_STATUS_NO_SUCH_DOMAIN. + wb_sids2xids_recv() failed with NT_STATUS_NO_SUCH_DOMAIN. [2025/07/21 17:46:17.569906, 1] source3/winbindd/wb_sids2xids.c:715(wb_sids2xids_gotdc) - Failed with NT_STATUS_NO_SUCH_DOMAIN. - - + Failed with NT_STATUS_NO_SUCH_DOMAIN. [ Where problems could occur ] * Think about what the upload changes in the software. Imagine the change is wrong or breaks something else: how would this show up? * It is assumed that any SRU candidate patch is well-tested before upload and has a low overall risk of regression, but it's important to make the effort to think about what ''could'' happen in the event of a regression. * This must never be "None" or "Low", or entirely an argument as to why your upload is low risk. * This both shows the SRU team that the risks have been considered, and provides guidance to testers in regression-testing the SRU. [ Other Info ] * Anything else you think is useful to include * Make sure to explain any deviation from the norm, to save the SRU reviewer from having to infer your reasoning, possibly incorrectly. This should also help reduce review iterations, particularly when the reason for the deviation is not obvious. * Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board and address these questions in advance https://lists.samba.org/archive/samba/2025-July/251814.html testing ppa: https://launchpad.net/~ahasenack/+archive/ubuntu/samba-netlogin-windows-update/+packages ** Description changed: [ Impact ] * An explanation of the effects of the bug on users and justification for backporting the fix to the stable release. * In addition, it is helpful, but not required, to include an explanation of how the upload fixes this bug. [ Test Plan ] Below is a test plan that satisfied the SRU criteria, but affected users are also invited to deploy the proposed packages to affected members servers in their existing networks to confirm the fix. The test plan below has to be carried out regardless of the above. # Deploy Windows Server with Active Directory, or use an existing domain. - # Apply all updates. In particular, make sure you have KB5062553 applied. + # Apply all updates. # As described, this test plan makes certain assumptions: # - active directory domain is EXAMPLE.COM # - IP of the AD server is 192.168.1.10/24 # - AD server is also acting as DNS (default with an AD deployment) # - gateway of the network is 192.168.1.1/24 # - uid/gid ranges for the idmap_ad backend as defined in the given smb.conf # Please adapt to your scenario if using an existing AD deployment. # Iterate over the ubuntu releases being tested export RELEASE=plucky lxc launch ubuntu-daily:$RELEASE member-test --vm # From here on, these commands are executed inside that vm lxc shell member-test # configure networking if needed. For example, for a fixed IP: cat > /etc/netplan/50-cloud-init.yaml <<EOF network: version: 2 ethernets: enp5s0: dhcp4: false addresses: [192.168.1.103/24] nameservers: search: [example.com] addresses: [192.168.1.10] routes: - to: default via: 192.168.1.1 EOF chmod 0600 /etc/netplan/50-cloud-init.yaml netplan apply # Depending on which packages are updated here, you might be logged out. Just # run "lxc shell" again if that happens. apt update && apt dist-upgrade -y apt install -y samba winbind libnss-winbind libpam-winbind # EXTRA STEP FOR JAMMY ONLY # add winbind to the end of the passwd and group lines in /etc/nsswitch.conf. # This command should do it: sed -i -r 's,(^(passwd:|group:)[[:blank:]]+.*)$,\1 winbind,' /etc/nsswitch.conf # But please check that these lines in /etc/nsswitch.conf look like shown below: passwd: files systemd winbind group: files systemd winbind # END OF JAMMY-ONLY EXTRA STEPS # Write this to /etc/samba/smb.conf: cat > /etc/samba/smb.conf <<EOF # Global parameters [global] kerberos method = secrets and keytab log file = /var/log/samba/log.%m logging = file map to guest = Bad User max log size = 1000 panic action = /usr/share/samba/panic-action %d realm = EXAMPLE.COM security = ADS server role = member server server string = %h server (Samba, Ubuntu) workgroup = EXAMPLE idmap config * : backend = tdb idmap config * : range = 3000-7999 idmap config example:backend = ad idmap config example:schema_mode = rfc2307 # 10.000 - 999.999 idmap config example:range = 10000-999999 idmap config example:unix_nss_info = no template shell = /bin/bash template homedir = /home/%U vfs objects = acl_xattr map acl inherit = yes store dos attributes = yes [printers] browseable = No comment = All Printers create mask = 0700 path = /var/tmp printable = Yes [print$] comment = Printer Drivers path = /var/lib/samba/printers EOF # Join the domain (you may get an error about failing to update the DNS entry, that's irrelevant for this test) net ads join -U Administrator # restart samba services systemctl restart smbd nmbd winbind # Test the join with these two commands: wbinfo -t net ads testjoin # Create a linux user in the domain with the following details: First name: Questing Last name: Ubuntu User logon name: questing UNCHECK: user must change password at next logon In the attribute editor tab (enable "Advanced features" in the View menu), locate the following attributes and fill them in as shown: uidNumber: 10002 # Check that the user is in the output of this command (careful: if using an existing AD domain, it might be best to not run this as there could be thousands of users): wbinfo -u # Now for the actual bug: flush the cache, and run the id command shown. If using the packages with the bug, the command will fail. If using the fixed packages, it will return user and group information: net cache flush id quest...@example.com # Failing case: id: ‘quest...@example.com’: no such user # Good case (output may vary depending on how the user was created; important point is that the user is "known"): uid=10002(EXAMPLE\questing) gid=10000(EXAMPLE\domain users) groups=10000(EXAMPLE\domain users),3001(BUILTIN\users) # In the failure case, you can also increase debugging of winbind with this command: smbcontrol winbind debug 4 # Note the debug level change above is not permanent, and will be lost if the service is restarted. # And then see failures in the /var/log/samba/log.winbindd log file: ==> /var/log/samba/log.winbindd <== [2025/07/21 17:45:35.313189, 0] source3/winbindd/winbindd_dual.c:1964(winbindd_sig_term_handler) Got sig[15] terminate (is_parent=1) [2025/07/21 17:45:35.359569, 0] source3/winbindd/winbindd.c:1441(main) winbindd version 4.19.5-Ubuntu started. Copyright Andrew Tridgell and the Samba Team 1992-2023 [2025/07/21 17:46:06.689406, 0] source4/lib/messaging/messaging.c:188(debug_imessage) debug_imessage: INFO: Remote set of debug to `4' (pid 2814 from pid 2850) [2025/07/21 17:46:06.689475, 3] lib/util/debug_s3.c:97(debug_message) INFO: Remote set of debug to `4' (pid 2814 from pid 2850) [2025/07/21 17:46:17.280262, 3] source3/winbindd/winbindd_misc.c:355(winbindd_interface_version) winbindd_interface_version: [nss_winbind (2858)]: request interface version (version = 32) [2025/07/21 17:46:17.280432, 3] source3/winbindd/winbindd.c:497(process_request_send) process_request_send: [nss_winbind (2858)] Handling async request: GETPWNAM [2025/07/21 17:46:17.280448, 3] source3/winbindd/winbindd_getpwnam.c:59(winbindd_getpwnam_send) [nss_winbind (2858)] Winbind external command GETPWNAM start. Query username 'quest...@example.com'. [2025/07/21 17:46:17.569589, 3] source3/winbindd/wb_dsgetdcname.c:135(wb_dsgetdcname_recv) Failed for example with NT_STATUS_NO_SUCH_DOMAIN. [2025/07/21 17:46:17.569658, 1] source3/winbindd/wb_sids2xids.c:765(wb_sids2xids_recv) Failed with NT_STATUS_NO_SUCH_DOMAIN. [2025/07/21 17:46:17.569686, 1] source3/winbindd/winbindd_getpwnam.c:142(winbindd_getpwnam_recv) Could not convert sid S-1-5-21-2226137316-1638043825-1947191812-1111: NT_STATUS_NO_SUCH_DOMAIN [2025/07/21 17:46:17.569698, 3] source3/winbindd/winbindd.c:564(process_request_done) process_request_done: [nss_winbind(2858):GETPWNAM]: NT_STATUS_NO_SUCH_DOMAIN [2025/07/21 17:46:17.569856, 1] source3/winbindd/wb_queryuser.c:123(wb_queryuser_got_uid) wb_sids2xids_recv() failed with NT_STATUS_NO_SUCH_DOMAIN. [2025/07/21 17:46:17.569906, 1] source3/winbindd/wb_sids2xids.c:715(wb_sids2xids_gotdc) Failed with NT_STATUS_NO_SUCH_DOMAIN. [ Where problems could occur ] * Think about what the upload changes in the software. Imagine the change is wrong or breaks something else: how would this show up? * It is assumed that any SRU candidate patch is well-tested before upload and has a low overall risk of regression, but it's important to make the effort to think about what ''could'' happen in the event of a regression. * This must never be "None" or "Low", or entirely an argument as to why your upload is low risk. * This both shows the SRU team that the risks have been considered, and provides guidance to testers in regression-testing the SRU. [ Other Info ] * Anything else you think is useful to include * Make sure to explain any deviation from the norm, to save the SRU reviewer from having to infer your reasoning, possibly incorrectly. This should also help reduce review iterations, particularly when the reason for the deviation is not obvious. * Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board and address these questions in advance https://lists.samba.org/archive/samba/2025-July/251814.html testing ppa: https://launchpad.net/~ahasenack/+archive/ubuntu/samba-netlogin-windows-update/+packages ** Description changed: [ Impact ] - * An explanation of the effects of the bug on users and justification - for backporting the fix to the stable release. - - * In addition, it is helpful, but not required, to include an - explanation of how the upload fixes this bug. + From the Samba Team announcement[1]: + + """ + On 8th of July, Microsoft will release an important security update for + Active Directory Domain Controllers for Windows Server versions prior to + 2025. + + This update includes a change to the Microsoft RPC Netlogon protocol, + which improves security by tightening access checks for a set of RPC + requests. Samba running as domain members in these environments will be + impacted by this change if a specific configuration is used, see below + for which configuration is affected. + + Windows Server version 2025 is already equipped with these specific + security hardenings, and Microsoft is now planning to deploy them to all + supported Windows Server versions down to Windows Server 2008. + + Who is affected? + + Samba installations acting as member servers in Windows AD domains will + be affected if they are configured to use the 'ad' idmapping backend. + Samba servers not using this configuration will not be affected by the + change – at least to our current knowledge and understanding of the + change – and no further action is required. + + Current versions of Samba with the affected configuration will no longer + function correctly once the Microsoft update has been applied. Users + will not be able to connect to the SMB service provided by Samba for any + domain configured to use the 'ad' idmapping backend. + """ + [ Test Plan ] Below is a test plan that satisfied the SRU criteria, but affected users are also invited to deploy the proposed packages to affected members servers in their existing networks to confirm the fix. The test plan below has to be carried out regardless of the above. # Deploy Windows Server with Active Directory, or use an existing domain. # Apply all updates. # As described, this test plan makes certain assumptions: # - active directory domain is EXAMPLE.COM # - IP of the AD server is 192.168.1.10/24 # - AD server is also acting as DNS (default with an AD deployment) # - gateway of the network is 192.168.1.1/24 # - uid/gid ranges for the idmap_ad backend as defined in the given smb.conf # Please adapt to your scenario if using an existing AD deployment. # Iterate over the ubuntu releases being tested export RELEASE=plucky lxc launch ubuntu-daily:$RELEASE member-test --vm # From here on, these commands are executed inside that vm lxc shell member-test # configure networking if needed. For example, for a fixed IP: cat > /etc/netplan/50-cloud-init.yaml <<EOF network: version: 2 ethernets: enp5s0: dhcp4: false addresses: [192.168.1.103/24] nameservers: search: [example.com] addresses: [192.168.1.10] routes: - to: default via: 192.168.1.1 EOF chmod 0600 /etc/netplan/50-cloud-init.yaml netplan apply # Depending on which packages are updated here, you might be logged out. Just # run "lxc shell" again if that happens. apt update && apt dist-upgrade -y apt install -y samba winbind libnss-winbind libpam-winbind # EXTRA STEP FOR JAMMY ONLY # add winbind to the end of the passwd and group lines in /etc/nsswitch.conf. # This command should do it: sed -i -r 's,(^(passwd:|group:)[[:blank:]]+.*)$,\1 winbind,' /etc/nsswitch.conf # But please check that these lines in /etc/nsswitch.conf look like shown below: passwd: files systemd winbind group: files systemd winbind # END OF JAMMY-ONLY EXTRA STEPS # Write this to /etc/samba/smb.conf: cat > /etc/samba/smb.conf <<EOF # Global parameters [global] kerberos method = secrets and keytab log file = /var/log/samba/log.%m logging = file map to guest = Bad User max log size = 1000 panic action = /usr/share/samba/panic-action %d realm = EXAMPLE.COM security = ADS server role = member server server string = %h server (Samba, Ubuntu) workgroup = EXAMPLE idmap config * : backend = tdb idmap config * : range = 3000-7999 idmap config example:backend = ad idmap config example:schema_mode = rfc2307 # 10.000 - 999.999 idmap config example:range = 10000-999999 idmap config example:unix_nss_info = no template shell = /bin/bash template homedir = /home/%U vfs objects = acl_xattr map acl inherit = yes store dos attributes = yes [printers] browseable = No comment = All Printers create mask = 0700 path = /var/tmp printable = Yes [print$] comment = Printer Drivers path = /var/lib/samba/printers EOF # Join the domain (you may get an error about failing to update the DNS entry, that's irrelevant for this test) net ads join -U Administrator # restart samba services systemctl restart smbd nmbd winbind # Test the join with these two commands: wbinfo -t net ads testjoin # Create a linux user in the domain with the following details: First name: Questing Last name: Ubuntu User logon name: questing UNCHECK: user must change password at next logon In the attribute editor tab (enable "Advanced features" in the View menu), locate the following attributes and fill them in as shown: uidNumber: 10002 # Check that the user is in the output of this command (careful: if using an existing AD domain, it might be best to not run this as there could be thousands of users): wbinfo -u # Now for the actual bug: flush the cache, and run the id command shown. If using the packages with the bug, the command will fail. If using the fixed packages, it will return user and group information: net cache flush id quest...@example.com # Failing case: id: ‘quest...@example.com’: no such user # Good case (output may vary depending on how the user was created; important point is that the user is "known"): uid=10002(EXAMPLE\questing) gid=10000(EXAMPLE\domain users) groups=10000(EXAMPLE\domain users),3001(BUILTIN\users) # In the failure case, you can also increase debugging of winbind with this command: smbcontrol winbind debug 4 # Note the debug level change above is not permanent, and will be lost if the service is restarted. # And then see failures in the /var/log/samba/log.winbindd log file: ==> /var/log/samba/log.winbindd <== [2025/07/21 17:45:35.313189, 0] source3/winbindd/winbindd_dual.c:1964(winbindd_sig_term_handler) Got sig[15] terminate (is_parent=1) [2025/07/21 17:45:35.359569, 0] source3/winbindd/winbindd.c:1441(main) winbindd version 4.19.5-Ubuntu started. Copyright Andrew Tridgell and the Samba Team 1992-2023 [2025/07/21 17:46:06.689406, 0] source4/lib/messaging/messaging.c:188(debug_imessage) debug_imessage: INFO: Remote set of debug to `4' (pid 2814 from pid 2850) [2025/07/21 17:46:06.689475, 3] lib/util/debug_s3.c:97(debug_message) INFO: Remote set of debug to `4' (pid 2814 from pid 2850) [2025/07/21 17:46:17.280262, 3] source3/winbindd/winbindd_misc.c:355(winbindd_interface_version) winbindd_interface_version: [nss_winbind (2858)]: request interface version (version = 32) [2025/07/21 17:46:17.280432, 3] source3/winbindd/winbindd.c:497(process_request_send) process_request_send: [nss_winbind (2858)] Handling async request: GETPWNAM [2025/07/21 17:46:17.280448, 3] source3/winbindd/winbindd_getpwnam.c:59(winbindd_getpwnam_send) [nss_winbind (2858)] Winbind external command GETPWNAM start. Query username 'quest...@example.com'. [2025/07/21 17:46:17.569589, 3] source3/winbindd/wb_dsgetdcname.c:135(wb_dsgetdcname_recv) Failed for example with NT_STATUS_NO_SUCH_DOMAIN. [2025/07/21 17:46:17.569658, 1] source3/winbindd/wb_sids2xids.c:765(wb_sids2xids_recv) Failed with NT_STATUS_NO_SUCH_DOMAIN. [2025/07/21 17:46:17.569686, 1] source3/winbindd/winbindd_getpwnam.c:142(winbindd_getpwnam_recv) Could not convert sid S-1-5-21-2226137316-1638043825-1947191812-1111: NT_STATUS_NO_SUCH_DOMAIN [2025/07/21 17:46:17.569698, 3] source3/winbindd/winbindd.c:564(process_request_done) process_request_done: [nss_winbind(2858):GETPWNAM]: NT_STATUS_NO_SUCH_DOMAIN [2025/07/21 17:46:17.569856, 1] source3/winbindd/wb_queryuser.c:123(wb_queryuser_got_uid) wb_sids2xids_recv() failed with NT_STATUS_NO_SUCH_DOMAIN. [2025/07/21 17:46:17.569906, 1] source3/winbindd/wb_sids2xids.c:715(wb_sids2xids_gotdc) Failed with NT_STATUS_NO_SUCH_DOMAIN. [ Where problems could occur ] * Think about what the upload changes in the software. Imagine the change is wrong or breaks something else: how would this show up? * It is assumed that any SRU candidate patch is well-tested before upload and has a low overall risk of regression, but it's important to make the effort to think about what ''could'' happen in the event of a regression. * This must never be "None" or "Low", or entirely an argument as to why your upload is low risk. * This both shows the SRU team that the risks have been considered, and provides guidance to testers in regression-testing the SRU. [ Other Info ] * Anything else you think is useful to include * Make sure to explain any deviation from the norm, to save the SRU reviewer from having to infer your reasoning, possibly incorrectly. This should also help reduce review iterations, particularly when the reason for the deviation is not obvious. * Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board and address these questions in advance https://lists.samba.org/archive/samba/2025-July/251814.html testing ppa: https://launchpad.net/~ahasenack/+archive/ubuntu/samba-netlogin-windows-update/+packages ** Description changed: [ Impact ] From the Samba Team announcement[1]: """ - On 8th of July, Microsoft will release an important security update for - Active Directory Domain Controllers for Windows Server versions prior to + On 8th of July, Microsoft will release an important security update for + Active Directory Domain Controllers for Windows Server versions prior to 2025. - This update includes a change to the Microsoft RPC Netlogon protocol, - which improves security by tightening access checks for a set of RPC - requests. Samba running as domain members in these environments will be - impacted by this change if a specific configuration is used, see below + This update includes a change to the Microsoft RPC Netlogon protocol, + which improves security by tightening access checks for a set of RPC + requests. Samba running as domain members in these environments will be + impacted by this change if a specific configuration is used, see below for which configuration is affected. - Windows Server version 2025 is already equipped with these specific - security hardenings, and Microsoft is now planning to deploy them to all + Windows Server version 2025 is already equipped with these specific + security hardenings, and Microsoft is now planning to deploy them to all supported Windows Server versions down to Windows Server 2008. Who is affected? - Samba installations acting as member servers in Windows AD domains will - be affected if they are configured to use the 'ad' idmapping backend. - Samba servers not using this configuration will not be affected by the - change – at least to our current knowledge and understanding of the + Samba installations acting as member servers in Windows AD domains will + be affected if they are configured to use the 'ad' idmapping backend. + Samba servers not using this configuration will not be affected by the + change – at least to our current knowledge and understanding of the change – and no further action is required. - Current versions of Samba with the affected configuration will no longer - function correctly once the Microsoft update has been applied. Users - will not be able to connect to the SMB service provided by Samba for any + Current versions of Samba with the affected configuration will no longer + function correctly once the Microsoft update has been applied. Users + will not be able to connect to the SMB service provided by Samba for any domain configured to use the 'ad' idmapping backend. """ - [ Test Plan ] Below is a test plan that satisfied the SRU criteria, but affected users are also invited to deploy the proposed packages to affected members servers in their existing networks to confirm the fix. The test plan below has to be carried out regardless of the above. - # Deploy Windows Server with Active Directory, or use an existing domain. + # Deploy Windows Server 2025 with Active Directory, or use an existing domain. # Apply all updates. # As described, this test plan makes certain assumptions: # - active directory domain is EXAMPLE.COM # - IP of the AD server is 192.168.1.10/24 # - AD server is also acting as DNS (default with an AD deployment) # - gateway of the network is 192.168.1.1/24 # - uid/gid ranges for the idmap_ad backend as defined in the given smb.conf # Please adapt to your scenario if using an existing AD deployment. # Iterate over the ubuntu releases being tested export RELEASE=plucky lxc launch ubuntu-daily:$RELEASE member-test --vm # From here on, these commands are executed inside that vm lxc shell member-test # configure networking if needed. For example, for a fixed IP: cat > /etc/netplan/50-cloud-init.yaml <<EOF network: version: 2 ethernets: enp5s0: dhcp4: false addresses: [192.168.1.103/24] nameservers: search: [example.com] addresses: [192.168.1.10] routes: - to: default via: 192.168.1.1 EOF chmod 0600 /etc/netplan/50-cloud-init.yaml netplan apply # Depending on which packages are updated here, you might be logged out. Just # run "lxc shell" again if that happens. apt update && apt dist-upgrade -y apt install -y samba winbind libnss-winbind libpam-winbind # EXTRA STEP FOR JAMMY ONLY # add winbind to the end of the passwd and group lines in /etc/nsswitch.conf. # This command should do it: sed -i -r 's,(^(passwd:|group:)[[:blank:]]+.*)$,\1 winbind,' /etc/nsswitch.conf # But please check that these lines in /etc/nsswitch.conf look like shown below: passwd: files systemd winbind group: files systemd winbind # END OF JAMMY-ONLY EXTRA STEPS # Write this to /etc/samba/smb.conf: cat > /etc/samba/smb.conf <<EOF # Global parameters [global] kerberos method = secrets and keytab log file = /var/log/samba/log.%m logging = file map to guest = Bad User max log size = 1000 panic action = /usr/share/samba/panic-action %d realm = EXAMPLE.COM security = ADS server role = member server server string = %h server (Samba, Ubuntu) workgroup = EXAMPLE idmap config * : backend = tdb idmap config * : range = 3000-7999 idmap config example:backend = ad idmap config example:schema_mode = rfc2307 # 10.000 - 999.999 idmap config example:range = 10000-999999 idmap config example:unix_nss_info = no template shell = /bin/bash template homedir = /home/%U vfs objects = acl_xattr map acl inherit = yes store dos attributes = yes [printers] browseable = No comment = All Printers create mask = 0700 path = /var/tmp printable = Yes [print$] comment = Printer Drivers path = /var/lib/samba/printers EOF # Join the domain (you may get an error about failing to update the DNS entry, that's irrelevant for this test) net ads join -U Administrator # restart samba services systemctl restart smbd nmbd winbind # Test the join with these two commands: wbinfo -t net ads testjoin # Create a linux user in the domain with the following details: First name: Questing Last name: Ubuntu User logon name: questing UNCHECK: user must change password at next logon In the attribute editor tab (enable "Advanced features" in the View menu), locate the following attributes and fill them in as shown: uidNumber: 10002 # Check that the user is in the output of this command (careful: if using an existing AD domain, it might be best to not run this as there could be thousands of users): wbinfo -u # Now for the actual bug: flush the cache, and run the id command shown. If using the packages with the bug, the command will fail. If using the fixed packages, it will return user and group information: net cache flush id quest...@example.com # Failing case: id: ‘quest...@example.com’: no such user # Good case (output may vary depending on how the user was created; important point is that the user is "known"): uid=10002(EXAMPLE\questing) gid=10000(EXAMPLE\domain users) groups=10000(EXAMPLE\domain users),3001(BUILTIN\users) # In the failure case, you can also increase debugging of winbind with this command: smbcontrol winbind debug 4 # Note the debug level change above is not permanent, and will be lost if the service is restarted. # And then see failures in the /var/log/samba/log.winbindd log file: ==> /var/log/samba/log.winbindd <== [2025/07/21 17:45:35.313189, 0] source3/winbindd/winbindd_dual.c:1964(winbindd_sig_term_handler) Got sig[15] terminate (is_parent=1) [2025/07/21 17:45:35.359569, 0] source3/winbindd/winbindd.c:1441(main) winbindd version 4.19.5-Ubuntu started. Copyright Andrew Tridgell and the Samba Team 1992-2023 [2025/07/21 17:46:06.689406, 0] source4/lib/messaging/messaging.c:188(debug_imessage) debug_imessage: INFO: Remote set of debug to `4' (pid 2814 from pid 2850) [2025/07/21 17:46:06.689475, 3] lib/util/debug_s3.c:97(debug_message) INFO: Remote set of debug to `4' (pid 2814 from pid 2850) [2025/07/21 17:46:17.280262, 3] source3/winbindd/winbindd_misc.c:355(winbindd_interface_version) winbindd_interface_version: [nss_winbind (2858)]: request interface version (version = 32) [2025/07/21 17:46:17.280432, 3] source3/winbindd/winbindd.c:497(process_request_send) process_request_send: [nss_winbind (2858)] Handling async request: GETPWNAM [2025/07/21 17:46:17.280448, 3] source3/winbindd/winbindd_getpwnam.c:59(winbindd_getpwnam_send) [nss_winbind (2858)] Winbind external command GETPWNAM start. Query username 'quest...@example.com'. [2025/07/21 17:46:17.569589, 3] source3/winbindd/wb_dsgetdcname.c:135(wb_dsgetdcname_recv) Failed for example with NT_STATUS_NO_SUCH_DOMAIN. [2025/07/21 17:46:17.569658, 1] source3/winbindd/wb_sids2xids.c:765(wb_sids2xids_recv) Failed with NT_STATUS_NO_SUCH_DOMAIN. [2025/07/21 17:46:17.569686, 1] source3/winbindd/winbindd_getpwnam.c:142(winbindd_getpwnam_recv) Could not convert sid S-1-5-21-2226137316-1638043825-1947191812-1111: NT_STATUS_NO_SUCH_DOMAIN [2025/07/21 17:46:17.569698, 3] source3/winbindd/winbindd.c:564(process_request_done) process_request_done: [nss_winbind(2858):GETPWNAM]: NT_STATUS_NO_SUCH_DOMAIN [2025/07/21 17:46:17.569856, 1] source3/winbindd/wb_queryuser.c:123(wb_queryuser_got_uid) wb_sids2xids_recv() failed with NT_STATUS_NO_SUCH_DOMAIN. [2025/07/21 17:46:17.569906, 1] source3/winbindd/wb_sids2xids.c:715(wb_sids2xids_gotdc) Failed with NT_STATUS_NO_SUCH_DOMAIN. [ Where problems could occur ] * Think about what the upload changes in the software. Imagine the change is wrong or breaks something else: how would this show up? * It is assumed that any SRU candidate patch is well-tested before upload and has a low overall risk of regression, but it's important to make the effort to think about what ''could'' happen in the event of a regression. * This must never be "None" or "Low", or entirely an argument as to why your upload is low risk. * This both shows the SRU team that the risks have been considered, and provides guidance to testers in regression-testing the SRU. [ Other Info ] * Anything else you think is useful to include * Make sure to explain any deviation from the norm, to save the SRU reviewer from having to infer your reasoning, possibly incorrectly. This should also help reduce review iterations, particularly when the reason for the deviation is not obvious. * Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board and address these questions in advance https://lists.samba.org/archive/samba/2025-July/251814.html testing ppa: https://launchpad.net/~ahasenack/+archive/ubuntu/samba-netlogin-windows-update/+packages ** Description changed: [ Impact ] From the Samba Team announcement[1]: """ On 8th of July, Microsoft will release an important security update for Active Directory Domain Controllers for Windows Server versions prior to 2025. This update includes a change to the Microsoft RPC Netlogon protocol, which improves security by tightening access checks for a set of RPC requests. Samba running as domain members in these environments will be impacted by this change if a specific configuration is used, see below for which configuration is affected. Windows Server version 2025 is already equipped with these specific security hardenings, and Microsoft is now planning to deploy them to all supported Windows Server versions down to Windows Server 2008. Who is affected? Samba installations acting as member servers in Windows AD domains will be affected if they are configured to use the 'ad' idmapping backend. Samba servers not using this configuration will not be affected by the change – at least to our current knowledge and understanding of the change – and no further action is required. Current versions of Samba with the affected configuration will no longer function correctly once the Microsoft update has been applied. Users will not be able to connect to the SMB service provided by Samba for any domain configured to use the 'ad' idmapping backend. """ [ Test Plan ] Below is a test plan that satisfied the SRU criteria, but affected users are also invited to deploy the proposed packages to affected members servers in their existing networks to confirm the fix. The test plan below has to be carried out regardless of the above. # Deploy Windows Server 2025 with Active Directory, or use an existing domain. # Apply all updates. # As described, this test plan makes certain assumptions: # - active directory domain is EXAMPLE.COM # - IP of the AD server is 192.168.1.10/24 # - AD server is also acting as DNS (default with an AD deployment) # - gateway of the network is 192.168.1.1/24 # - uid/gid ranges for the idmap_ad backend as defined in the given smb.conf # Please adapt to your scenario if using an existing AD deployment. # Iterate over the ubuntu releases being tested export RELEASE=plucky lxc launch ubuntu-daily:$RELEASE member-test --vm # From here on, these commands are executed inside that vm lxc shell member-test # configure networking if needed. For example, for a fixed IP: cat > /etc/netplan/50-cloud-init.yaml <<EOF network: version: 2 ethernets: enp5s0: dhcp4: false addresses: [192.168.1.103/24] nameservers: search: [example.com] addresses: [192.168.1.10] routes: - to: default via: 192.168.1.1 EOF chmod 0600 /etc/netplan/50-cloud-init.yaml netplan apply # Depending on which packages are updated here, you might be logged out. Just # run "lxc shell" again if that happens. apt update && apt dist-upgrade -y apt install -y samba winbind libnss-winbind libpam-winbind # EXTRA STEP FOR JAMMY ONLY # add winbind to the end of the passwd and group lines in /etc/nsswitch.conf. # This command should do it: sed -i -r 's,(^(passwd:|group:)[[:blank:]]+.*)$,\1 winbind,' /etc/nsswitch.conf # But please check that these lines in /etc/nsswitch.conf look like shown below: passwd: files systemd winbind group: files systemd winbind # END OF JAMMY-ONLY EXTRA STEPS # Write this to /etc/samba/smb.conf: cat > /etc/samba/smb.conf <<EOF # Global parameters [global] kerberos method = secrets and keytab log file = /var/log/samba/log.%m logging = file map to guest = Bad User max log size = 1000 panic action = /usr/share/samba/panic-action %d realm = EXAMPLE.COM security = ADS server role = member server server string = %h server (Samba, Ubuntu) workgroup = EXAMPLE idmap config * : backend = tdb idmap config * : range = 3000-7999 idmap config example:backend = ad idmap config example:schema_mode = rfc2307 # 10.000 - 999.999 idmap config example:range = 10000-999999 idmap config example:unix_nss_info = no template shell = /bin/bash template homedir = /home/%U vfs objects = acl_xattr map acl inherit = yes store dos attributes = yes [printers] browseable = No comment = All Printers create mask = 0700 path = /var/tmp printable = Yes [print$] comment = Printer Drivers path = /var/lib/samba/printers EOF # Join the domain (you may get an error about failing to update the DNS entry, that's irrelevant for this test) net ads join -U Administrator # restart samba services systemctl restart smbd nmbd winbind # Test the join with these two commands: wbinfo -t net ads testjoin # Create a linux user in the domain with the following details: First name: Questing Last name: Ubuntu User logon name: questing UNCHECK: user must change password at next logon In the attribute editor tab (enable "Advanced features" in the View menu), locate the following attributes and fill them in as shown: uidNumber: 10002 # Check that the user is in the output of this command (careful: if using an existing AD domain, it might be best to not run this as there could be thousands of users): wbinfo -u # Now for the actual bug: flush the cache, and run the id command shown. If using the packages with the bug, the command will fail. If using the fixed packages, it will return user and group information: net cache flush id quest...@example.com # Failing case: id: ‘quest...@example.com’: no such user # Good case (output may vary depending on how the user was created; important point is that the user is "known"): uid=10002(EXAMPLE\questing) gid=10000(EXAMPLE\domain users) groups=10000(EXAMPLE\domain users),3001(BUILTIN\users) # In the failure case, you can also increase debugging of winbind with this command: smbcontrol winbind debug 4 # Note the debug level change above is not permanent, and will be lost if the service is restarted. # And then see failures in the /var/log/samba/log.winbindd log file: ==> /var/log/samba/log.winbindd <== [2025/07/21 17:45:35.313189, 0] source3/winbindd/winbindd_dual.c:1964(winbindd_sig_term_handler) Got sig[15] terminate (is_parent=1) [2025/07/21 17:45:35.359569, 0] source3/winbindd/winbindd.c:1441(main) winbindd version 4.19.5-Ubuntu started. Copyright Andrew Tridgell and the Samba Team 1992-2023 [2025/07/21 17:46:06.689406, 0] source4/lib/messaging/messaging.c:188(debug_imessage) debug_imessage: INFO: Remote set of debug to `4' (pid 2814 from pid 2850) [2025/07/21 17:46:06.689475, 3] lib/util/debug_s3.c:97(debug_message) INFO: Remote set of debug to `4' (pid 2814 from pid 2850) [2025/07/21 17:46:17.280262, 3] source3/winbindd/winbindd_misc.c:355(winbindd_interface_version) winbindd_interface_version: [nss_winbind (2858)]: request interface version (version = 32) [2025/07/21 17:46:17.280432, 3] source3/winbindd/winbindd.c:497(process_request_send) process_request_send: [nss_winbind (2858)] Handling async request: GETPWNAM [2025/07/21 17:46:17.280448, 3] source3/winbindd/winbindd_getpwnam.c:59(winbindd_getpwnam_send) [nss_winbind (2858)] Winbind external command GETPWNAM start. Query username 'quest...@example.com'. [2025/07/21 17:46:17.569589, 3] source3/winbindd/wb_dsgetdcname.c:135(wb_dsgetdcname_recv) Failed for example with NT_STATUS_NO_SUCH_DOMAIN. [2025/07/21 17:46:17.569658, 1] source3/winbindd/wb_sids2xids.c:765(wb_sids2xids_recv) Failed with NT_STATUS_NO_SUCH_DOMAIN. [2025/07/21 17:46:17.569686, 1] source3/winbindd/winbindd_getpwnam.c:142(winbindd_getpwnam_recv) Could not convert sid S-1-5-21-2226137316-1638043825-1947191812-1111: NT_STATUS_NO_SUCH_DOMAIN [2025/07/21 17:46:17.569698, 3] source3/winbindd/winbindd.c:564(process_request_done) process_request_done: [nss_winbind(2858):GETPWNAM]: NT_STATUS_NO_SUCH_DOMAIN [2025/07/21 17:46:17.569856, 1] source3/winbindd/wb_queryuser.c:123(wb_queryuser_got_uid) wb_sids2xids_recv() failed with NT_STATUS_NO_SUCH_DOMAIN. [2025/07/21 17:46:17.569906, 1] source3/winbindd/wb_sids2xids.c:715(wb_sids2xids_gotdc) Failed with NT_STATUS_NO_SUCH_DOMAIN. [ Where problems could occur ] * Think about what the upload changes in the software. Imagine the change is wrong or breaks something else: how would this show up? * It is assumed that any SRU candidate patch is well-tested before upload and has a low overall risk of regression, but it's important to make the effort to think about what ''could'' happen in the event of a regression. * This must never be "None" or "Low", or entirely an argument as to why your upload is low risk. * This both shows the SRU team that the risks have been considered, and provides guidance to testers in regression-testing the SRU. [ Other Info ] * Anything else you think is useful to include * Make sure to explain any deviation from the norm, to save the SRU reviewer from having to infer your reasoning, possibly incorrectly. This should also help reduce review iterations, particularly when the reason for the deviation is not obvious. * Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board and address these questions in advance - https://lists.samba.org/archive/samba/2025-July/251814.html - testing ppa: https://launchpad.net/~ahasenack/+archive/ubuntu/samba-netlogin-windows-update/+packages + 1. https://lists.samba.org/archive/samba/2025-July/251814.html + 2. testing ppa: https://launchpad.net/~ahasenack/+archive/ubuntu/samba-netlogin-windows-update/+packages ** Description changed: [ Impact ] From the Samba Team announcement[1]: """ On 8th of July, Microsoft will release an important security update for Active Directory Domain Controllers for Windows Server versions prior to 2025. This update includes a change to the Microsoft RPC Netlogon protocol, which improves security by tightening access checks for a set of RPC requests. Samba running as domain members in these environments will be impacted by this change if a specific configuration is used, see below for which configuration is affected. Windows Server version 2025 is already equipped with these specific security hardenings, and Microsoft is now planning to deploy them to all supported Windows Server versions down to Windows Server 2008. Who is affected? Samba installations acting as member servers in Windows AD domains will be affected if they are configured to use the 'ad' idmapping backend. Samba servers not using this configuration will not be affected by the change – at least to our current knowledge and understanding of the change – and no further action is required. Current versions of Samba with the affected configuration will no longer function correctly once the Microsoft update has been applied. Users will not be able to connect to the SMB service provided by Samba for any domain configured to use the 'ad' idmapping backend. """ [ Test Plan ] - Below is a test plan that satisfied the SRU criteria, but affected users are also invited to deploy the proposed packages to affected members servers in their existing networks to confirm the fix. + Below is a test plan that satisfies the SRU criteria, but affected users are also invited to deploy the proposed samba packages to affected members servers in their existing networks to confirm the fix. The test plan below has to be carried out regardless of the above. # Deploy Windows Server 2025 with Active Directory, or use an existing domain. # Apply all updates. # As described, this test plan makes certain assumptions: # - active directory domain is EXAMPLE.COM # - IP of the AD server is 192.168.1.10/24 # - AD server is also acting as DNS (default with an AD deployment) # - gateway of the network is 192.168.1.1/24 # - uid/gid ranges for the idmap_ad backend as defined in the given smb.conf # Please adapt to your scenario if using an existing AD deployment. # Iterate over the ubuntu releases being tested export RELEASE=plucky lxc launch ubuntu-daily:$RELEASE member-test --vm # From here on, these commands are executed inside that vm lxc shell member-test # configure networking if needed. For example, for a fixed IP: cat > /etc/netplan/50-cloud-init.yaml <<EOF network: version: 2 ethernets: enp5s0: dhcp4: false addresses: [192.168.1.103/24] nameservers: search: [example.com] addresses: [192.168.1.10] routes: - to: default via: 192.168.1.1 EOF chmod 0600 /etc/netplan/50-cloud-init.yaml netplan apply # Depending on which packages are updated here, you might be logged out. Just # run "lxc shell" again if that happens. apt update && apt dist-upgrade -y apt install -y samba winbind libnss-winbind libpam-winbind # EXTRA STEP FOR JAMMY ONLY # add winbind to the end of the passwd and group lines in /etc/nsswitch.conf. # This command should do it: sed -i -r 's,(^(passwd:|group:)[[:blank:]]+.*)$,\1 winbind,' /etc/nsswitch.conf # But please check that these lines in /etc/nsswitch.conf look like shown below: passwd: files systemd winbind group: files systemd winbind # END OF JAMMY-ONLY EXTRA STEPS # Write this to /etc/samba/smb.conf: cat > /etc/samba/smb.conf <<EOF # Global parameters [global] kerberos method = secrets and keytab log file = /var/log/samba/log.%m logging = file map to guest = Bad User max log size = 1000 panic action = /usr/share/samba/panic-action %d realm = EXAMPLE.COM security = ADS server role = member server server string = %h server (Samba, Ubuntu) workgroup = EXAMPLE idmap config * : backend = tdb idmap config * : range = 3000-7999 idmap config example:backend = ad idmap config example:schema_mode = rfc2307 # 10.000 - 999.999 idmap config example:range = 10000-999999 idmap config example:unix_nss_info = no template shell = /bin/bash template homedir = /home/%U vfs objects = acl_xattr map acl inherit = yes store dos attributes = yes [printers] browseable = No comment = All Printers create mask = 0700 path = /var/tmp printable = Yes [print$] comment = Printer Drivers path = /var/lib/samba/printers EOF # Join the domain (you may get an error about failing to update the DNS entry, that's irrelevant for this test) net ads join -U Administrator # restart samba services systemctl restart smbd nmbd winbind # Test the join with these two commands: wbinfo -t net ads testjoin # Create a linux user in the domain with the following details: First name: Questing Last name: Ubuntu User logon name: questing UNCHECK: user must change password at next logon In the attribute editor tab (enable "Advanced features" in the View menu), locate the following attributes and fill them in as shown: uidNumber: 10002 # Check that the user is in the output of this command (careful: if using an existing AD domain, it might be best to not run this as there could be thousands of users): wbinfo -u # Now for the actual bug: flush the cache, and run the id command shown. If using the packages with the bug, the command will fail. If using the fixed packages, it will return user and group information: net cache flush id quest...@example.com # Failing case: id: ‘quest...@example.com’: no such user # Good case (output may vary depending on how the user was created; important point is that the user is "known"): uid=10002(EXAMPLE\questing) gid=10000(EXAMPLE\domain users) groups=10000(EXAMPLE\domain users),3001(BUILTIN\users) # In the failure case, you can also increase debugging of winbind with this command: smbcontrol winbind debug 4 # Note the debug level change above is not permanent, and will be lost if the service is restarted. # And then see failures in the /var/log/samba/log.winbindd log file: ==> /var/log/samba/log.winbindd <== [2025/07/21 17:45:35.313189, 0] source3/winbindd/winbindd_dual.c:1964(winbindd_sig_term_handler) Got sig[15] terminate (is_parent=1) [2025/07/21 17:45:35.359569, 0] source3/winbindd/winbindd.c:1441(main) winbindd version 4.19.5-Ubuntu started. Copyright Andrew Tridgell and the Samba Team 1992-2023 [2025/07/21 17:46:06.689406, 0] source4/lib/messaging/messaging.c:188(debug_imessage) debug_imessage: INFO: Remote set of debug to `4' (pid 2814 from pid 2850) [2025/07/21 17:46:06.689475, 3] lib/util/debug_s3.c:97(debug_message) INFO: Remote set of debug to `4' (pid 2814 from pid 2850) [2025/07/21 17:46:17.280262, 3] source3/winbindd/winbindd_misc.c:355(winbindd_interface_version) winbindd_interface_version: [nss_winbind (2858)]: request interface version (version = 32) [2025/07/21 17:46:17.280432, 3] source3/winbindd/winbindd.c:497(process_request_send) process_request_send: [nss_winbind (2858)] Handling async request: GETPWNAM [2025/07/21 17:46:17.280448, 3] source3/winbindd/winbindd_getpwnam.c:59(winbindd_getpwnam_send) [nss_winbind (2858)] Winbind external command GETPWNAM start. Query username 'quest...@example.com'. [2025/07/21 17:46:17.569589, 3] source3/winbindd/wb_dsgetdcname.c:135(wb_dsgetdcname_recv) Failed for example with NT_STATUS_NO_SUCH_DOMAIN. [2025/07/21 17:46:17.569658, 1] source3/winbindd/wb_sids2xids.c:765(wb_sids2xids_recv) Failed with NT_STATUS_NO_SUCH_DOMAIN. [2025/07/21 17:46:17.569686, 1] source3/winbindd/winbindd_getpwnam.c:142(winbindd_getpwnam_recv) Could not convert sid S-1-5-21-2226137316-1638043825-1947191812-1111: NT_STATUS_NO_SUCH_DOMAIN [2025/07/21 17:46:17.569698, 3] source3/winbindd/winbindd.c:564(process_request_done) process_request_done: [nss_winbind(2858):GETPWNAM]: NT_STATUS_NO_SUCH_DOMAIN [2025/07/21 17:46:17.569856, 1] source3/winbindd/wb_queryuser.c:123(wb_queryuser_got_uid) wb_sids2xids_recv() failed with NT_STATUS_NO_SUCH_DOMAIN. [2025/07/21 17:46:17.569906, 1] source3/winbindd/wb_sids2xids.c:715(wb_sids2xids_gotdc) Failed with NT_STATUS_NO_SUCH_DOMAIN. [ Where problems could occur ] * Think about what the upload changes in the software. Imagine the change is wrong or breaks something else: how would this show up? * It is assumed that any SRU candidate patch is well-tested before upload and has a low overall risk of regression, but it's important to make the effort to think about what ''could'' happen in the event of a regression. * This must never be "None" or "Low", or entirely an argument as to why your upload is low risk. * This both shows the SRU team that the risks have been considered, and provides guidance to testers in regression-testing the SRU. [ Other Info ] * Anything else you think is useful to include * Make sure to explain any deviation from the norm, to save the SRU reviewer from having to infer your reasoning, possibly incorrectly. This should also help reduce review iterations, particularly when the reason for the deviation is not obvious. * Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board and address these questions in advance 1. https://lists.samba.org/archive/samba/2025-July/251814.html 2. testing ppa: https://launchpad.net/~ahasenack/+archive/ubuntu/samba-netlogin-windows-update/+packages -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2116098 Title: Windows security hardening locks out schannel'ed netlogon dc calls To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/samba/+bug/2116098/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
